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Foreword 



byPhilMoorby 

The creator of the Verilog language 



When Verilog was created in the mid-1980s, the typical design size was of the order 
of five to ten thousand gates, the typical design creation method was that of using 
graphical schematic entry tools, and simulation was beginning to be an essential gate 
level verification tool. Verilog addressed the problems of the day, but also included 
capabilities that enabled a new generation of EDA technology to evolve, namely syn- 
thesis from RTL. Verilog thus became the mainstay language of IC designers. 

Throughout the 1990's, the Verilog language continued to evolve with technology, 
and the IEEE ratified new extensions to the standard in 2001. Most of the new capa- 
bilities in the 2001 standard that users were eagerly waiting for were relatively minor 
feature refinements as found in other HDLs, such as multidimensional arrays, auto- 
matic variables and the generate statement. Today many EDA tools support these 
Verilog-2001 enhancements, and thus provide users with access to these new capabil- 
ities. 

SystemVerilog is a significant new enhancement to Verilog and includes major exten- 
sions into abstract design, testbench, formal, and C-based APIs. SystemVerilog also 
defines new layers in the Verilog simulation strata. These extensions provide signifi- 
cant new capabilities to the designer, verification engineer and architect, allowing 
better teamwork and co-ordination between different project members. As was the 
case with the original Verilog, teams who adopt SystemVerilog based tools will be 
more productive and produce better quality designs in shorter periods. 

A strong guiding requirement for SystemVerilog is that it should be a true superset of 
Verilog, and as new tools become available, I believe all Verilog users, and many 
users of other HDLs, will naturally adopt it. 

When I developed the original Verilog LRM and simulator, I had an expectation of 
maybe a 10-15 year life-span, and during this time I have kept involved with its evo- 




lution. When Co-Design Automation was formed by two of the authors, Peter Flake 
and Simon Davidmann, to develop SUPERLOG and evolve Verilog, I was invited to 
join its Technical Advisory Board and, later, I joined the company and chaired its 
SUPERLOG Working Group. More recently, SUPERLOG was adopted by Accellera 
and has become the basis of SystemVerilog. I did not expect Verilog to be as success- 
ful as it has been and, with the extensions in SystemVerilog, I believe that it will now 
become the dominant HDL and provide significant benefits to the current and future 
generation of hardware designers, architects and verification engineers, as they 
endeavor to create smaller, better, faster, cheaper products. 

If you are a designer or architect building digital systems, or a verification engineer 
searching for bugs in these designs, then SystemVerilog will provide you with signif- 
icant benefits, and this book is a great place to start to learn SystemVerilog and the 
future of Hardware Design and Verification Languages. 



Phil Moorby, 
New England , 2003 




Preface 



SystemVerilog, an Accellera standard 1 , is a set of extensions to the IEEE Std. 1364- 
2001™ Verilog Standard (commonly referred to as “Verilog-2001”). These exten- 
sions provide new and powerful language constructs for modeling and verifying the 
behavior of designs that are ever increasing in size and complexity. The SystemVer- 
ilog extensions to Verilog can be generalized to two primary categories: 

• Enhancements primarily addressing the needs of hardware modeling, both in terms 
of overall efficiency and abstraction levels. 

• Verification enhancements and assertions for writing efficient, race-free test- 
benches for very large, complex designs. 

Accordingly, the discussion of SystemVerilog is divided into two books. This book, 
SystemVerilog for Design , addresses the first category, using SystemVerilog for 
modeling hardware designs at the RTL and system levels of abstraction. Most of the 
examples in this book can be realized in hardware, and are synthesizable. A forthcom- 
ing companion book, SystemVerilog for Verification , will cover the second purpose 
of SystemVerilog, that of verifying correct functionality of large, complex designs. 
This companion book is expected to be available in June, 2004. 



Target audience 




This book assumes the reader is already familiar with the Verilog Hardware 
Description Language. 



This book is intended to help users of the Verilog language understand the potential 
and capabilities of the SystemVerilog enhancements to Verilog. The book presents 
SystemVerilog in the context of examples, with an emphasis on correct usage of Sys- 
temVerilog constructs. These examples include a mix of standard Verilog code along 
with SystemVerilog the enhancements. The explanations in the book focus on these 
SystemVerilog enhancements, with an assumption that the reader will understand the 
Verilog portions of the examples. 

Additional references on SystemVerilog and Verilog are listed on page xxvi. 



1. Chapter 1 provides more information about the Accellera standards organization, 
and the development of the SystemVerilog standard. 




Topics covered 



This book focusses on the portion of SystemVerilog that is intended for representing 
hardware designs in a manner that is both simulatable and synthesizable. 

Chapter 1 presents a brief overview of SystemVerilog and the key enhancements that 
it adds to the Verilog language. 

Chapter 2 goes into detail on the many new data types SystemVerilog adds to Ver- 
ilog. The chapter covers the intended and proper usage of these new data types. 

Chapter 3 presents user-defined data types, a powerful enhancement to Verilog. The 
topics include how to create new data type definitions using typed© f and defining 
enumerated type variables. 

Chapter 4 looks at using structures and unions in hardware models. The chapter also 
presents a number of enhancements to arrays, together with suggestions as to how 
they can be used as abstract modeling constructs. 

Chapter 5 presents the specialized procedural blocks, coding blocks and enhanced 
task and function definitions in SystemVerilog, and how these enhancements will 
help create models that are correct by design. 

Chapter 6 shows how to use the enhancements to Verilog operators and procedural 
statements to code accurate and deterministic hardware models, using fewer lines of 
code compared to standard Verilog. 

Chapter 7 provides guidelines on how to use enumerated types and specialized pro- 
cedural blocks for modeling Finite State Machine (FSM) designs. This chapter also 
presents a number of guidelines on how to model a design using 2-state logic. 

Chapter 8 examines the enhancements to design hierarchy that SystemVerilog pro- 
vides. Significant constructs are presented, including nested module declarations and 
simplified module instance declarations. 

Chapter 9 discusses the powerful interface construct that SystemVerilog adds to Ver- 
ilog. Interfaces greatly simplify the representation of complex busses and enable the 
creation of more intelligent, easier to use IP (intellectual property) models. 

Chapter 10 ties together the concepts from all the previous chapters by applying 
them to a much more extensive example. The example shows a complete model of an 
ATM switch design, modeled in SystemVerilog. 



XXIV 




Chapter 11 provides another complete example of using SystemVerilog. This chap- 
ter covers the usage of SystemVerilog to represent models at a much higher level of 
abstraction, using transactions. 

Appendix A lists the formal syntax of SystemVerilog using the Backus-Naur Form 
(BNF). The SystemVerilog BNF includes the full Verilog-2001 BNF, showing how 
SystemVerilog is an extension of Verilog. 

Appendix B presents an informative history of hardware description languages and 
Verilog. It covers the development of the SUPERLOG language, which became the 
basis for much of the synthesizable modeling constructs in SystemVerilog. 



About the examples in this book 

The examples in this book are intended to illustrate specific SystemVerilog constructs 
in a realistic but brief context. To maintain that focus, many of the examples are rela- 
tively small, and often do not reflect the full context of a complete model. However, 
the examples serve to show the proper usage of SystemVerilog constructs. To show 
the power of SystemVerilog in a more complete context, Chapter 10 contains the full 
source code of a more extensive example. 

The examples contained in the book use the convention of showing all Verilog and 
SystemVerilog keywords in bold, as illustrated below: 

Example: SystemVerilog code sample 

module uart (output logic [7:0] data, 

output logic data_rdy, 

input serial_in) ; 

enum {WAIT, LOAD, READY} State, NextState; 

bit [2:0] bit__cnt; 

bit cntr_rst, shiftmen; 

always_ff @(posedge clock, negedge resetN) begin: shifter 
if (! resetN) 

data <= 8 ' hO ; //reset (active low) 

else if (shiftmen) 

data <= {serial__in, data[7:l]}; //shift right 
end: shifter 
endmodule 
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Longer examples in this book list the code between double horizontal lines, as shown 
above. There are also many shorter examples in each chapter that are embedded in the 
body of the text, without the use of horizontal lines to set them apart. For both styles 
of examples, the full source code is not always included in the book. This was done in 
order to focus on specific aspects of SystemVerilog constructs without excessive clut- 
ter from surrounding code. 




The examples do not distinguish standard Verilog constructs and keywords from 
SystemVerilog constructs and keywords. It is expected that the reader is already 
familiar with the Verilog HDL, and will recognize standard Verilog versus the new 
constructs and keywords added with SystemVerilog. 



Obtaining copies of the examples 

The complete code for all the examples listed in this book are available for personal, 
non-commercial use. They can be downloaded from http://www.sutherland~hdl.com . 
Navigate the links to “System Verilog for Design Book Examples”. 



Example testing 

Most examples in this book have been tested using the Synopsys VCS® simulator, 
version 7.1. Many examples have also been tested with the Model Technology (a 
Mentor Graphics company) ModelSim™ simulator, version 5.8. Most models in this 
book are synthesizable, and have been tested using the Synopsys HDL Compiler™ 
synthesis compiler, version 2003. 12. 1 



Other sources of information 

This book explains only the SystemVerilog enhancements for modeling hardware 
designs. The book does not go into detail on the SystemVerilog enhancements for 
verification, and does not cover the Verilog standard. Some other resources which can 
serve as an excellent companion to this book are: 



1 . All company names and product names mentioned in this book are the trademark or registered 
trademark names of their respective companies. 
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SystemVerilog for Verification by Janick Bergeron, Tom Fitzpatrick, Arturo Salz, 
and Stuart Sutherland. 

Anticipated to be published about June 2004, Kluwer Academic Publishers, Nor- 
well MA. ISBN not yet assigned. 

A companion to this book, with a focus on verification methodology using the 
SystemVerilog assertion and testbench enhancements to Verilog. For more infor- 
mation, visit the web site www.wkap.nl , and search for books on SystemVerilog. 

System Verilog 3.1 Language Reference Manual, Accellera *s Extensions to Verilog. 

The official definition of the SystemVerilog standard, as defined by the Accellera 
Standards Organization. The latest released version of the Accellera SystemVer- 
ilog LRM is available as a PDF document at www.accellera.org. 

IEEE Std 1364-2001, Language Reference Manual LRM) — IEEE Standard Hard- 
ware Description Language based on the Verilog Hardware Description Language. 

Copyright 2001, IEEE, Inc, New York, NY. ISBN 0-7381-2827-9. Softcover, 
665 pages (also available as a downloadable PDF file). 

This is the official Verilog HDL and PLI standard. The book is a syntax and 
semantics reference, not a tutorial for learning Verilog. For information on order- 
ing, visit the web site: http://shop.ieee.org/store and search for Verilog, or call 1- 
800-678-4333 (US and Canada), 1-908-981-9667 (elsewhere). 

1364.1-2002 IEEE Standard for Verilog Register Transfer Level Synthesis 2002 — 
Standard syntax and semantics for Verilog HDL-based RTL synthesis. 

Copyright 2002, IEEE, Inc, New York, NY. ISBN 0-7381-3501-1. Softcover, 
106 pages (also available as a downloadable PDF file). 

This is the official synthesizable subset of the Verilog language. For information on 
ordering, visit the web site: http://shop.ieee.org/store and search for Verilog, or call 
1-800-678-4333 (US and Canada), 1-908-981-9667 (elsewhere). 

The Verilog Hardware Description Language, 5th Edition by Donald E. Thomas 
and Philip R. Moorby. 

Copyright 2002, Kluwer Academic Publishers, Norwell MA. 

ISBN: 1-4020-7089-6. Hardcover, 408 pages. 

A complete book on Verilog, covering RTL modeling, behavioral modeling and 
gate level modeling. The book has more detail on the gate, switch and strength 
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level aspects of Verilog than many other books. For more information, refer to the 
web site www.wkap.nl/prod/b/1-4020-7089-6. 

Verilog Quickstart, A Practical Guide to Simulation and Synthesis, 3rd Edition by 
James M. Lee. 

Copyright 2002, Kluwer Academic Publishers, Norwell MA. 

ISBN: 0-7923-7672-2. Hardcover, 384 pages. 

An excellent book for learning the Verilog HDL. The book teaches the basics of 
Verilog modeling, without getting bogged down with the more obscure aspects of 
the Verilog language. For more information, refer to the web site www.wkap.nl/ 
prod/b/0- 7923- 76 72-2. 

Verilog 2001: A Guide to the New Features of the Verilog Hardware Description 
Language by Stuart Sutherland. 

Copyright 2002, Kluwer Academic Publishers, Norwell MA. 

ISBN: 0-7923-7568-8. Hardcover, 136 pages. 

An overview of the many enhancements added as part of the IEEE 1364-2001 
standard. For more information, refer to the web site www.wkap.nl/book.htm/0- 
7923-7568-8. 
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Chapter 1 

Introduction to SystemVerilog 



r his chapter provides an overview of SystemVerilog. The top- 
ics presented in this chapter include: 

• The origins of SystemVerilog 
• Technical donations that went into SystemVerilog 
• Highlights of key SystemVerilog features 



1,1 SystemVerilog origins 

SystemVerilog SystemVerilog is a standard set of extensions to the IEEE Std. 
extends Verilog 1364-2001 Verilog Standard (commonly referred to as “Verilog- 
2001"). The SystemVerilog extensions to the Verilog HDL that are 
described in this book are targeted at design and writing synthesiz- 
able models. These extensions integrate many of the best features 
of the SUPERLOG and C languages. SystemVerilog also contains a 
large number of extensions targeted toward verification of large 
designs. These verification extensions integrate features from the 
SUPERLOG, VERA C, C++, and VHDL languages, along with 
OVA assertions and PSL assertions (formerly known as Sugar). 
These verification assertions are in a forthcoming companion book, 
SystemVerilog for Verification . 
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This integrated whole created by SystemVerilog greatly exceeds 
the sum of its individual components, creating a new type of engi- 
neering language, a Hardware Description and Verification Lan- 
guage or HDVL. Using a single, unified language enables 
engineers to model large, complex designs, and verify that these 
designs are functionally correct. 

SystemVerilog The SystemVerilog enhancements are being defined by a standards 
will become part group under the auspices of the Accellera Standards Organization , 
of the IEEE rather than directly by the IEEE. Accellera’s stated goal is to turn 
Verilog standard the definition of SystemVerilog over to the IEEE for ratification as 
part of the full IEEE 1364 standard. It is expected that SystemVer- 
ilog will be a major portion of the next generation of the Verilog 
standard. 

The Accellera standards organization 

Accellera Accellera is a non-profit organization with the goal of supporting 
promotes the the development and use of Electronic Design Automation (EDA) 
development of languages. Accellera is he combined VHDL International and Open 
EDA tools Verilog International organizations. Accellera helps sponsor the 
IEEE 1076 VHDL and IEEE 1364 Verilog standards groups. In 
addition, Accellera sponsors a number of committees doing 
research on future languages. SystemVerilog is the result of one of 
those Accellera committees. Accellera itself receives its funding 
from member companies. These companies comprise several major 
EDA software vendors and several major electronic design corpora- 
tions. More information on Accellera, its members, and its current 
projects can be found at www.accellera.org . 

SystemVerilog Accellera has based the SystemVerilog enhancements to Verilog on 
is based on proven technologies. Various companies have donated technology 
proven to Accellera, which has then been carefully reviewed and integrated 
technology j n t 0 SystemVerilog. A major benefit of using donations of technol- 
ogies is that the SystemVerilog enhancements have already been 
proven to work and accomplish the objective of modeling and veri- 
fying much larger designs. 

1.1.1 The Accellera SystemVerilog standard 
SystemVerilog 

3.0 extends ^ major portion of SystemVerilog was released as an Accellera 
modeling standard in June of 2002 under the title of SystemVerilog 3.0. This 
capability initial release of the SystemVerilog standard allowed EDA compa- 
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nies to begin adding the SystemVerilog extensions to existing sim- 
ulators, synthesis compilers and other engineering tools. The focus 
of this first release of the SystemVerilog standard was to extend the 
synthesizable constructs of Verilog, and to enable modeling hard- 
ware at a higher level of abstraction. These are the constructs that 
are addressed in this book. 

SystemVerilog A major update to the SystemVerilog set of extensions was released 
3.1 extends in May of 2003. This release is referred to as SystemVerilog 3.1 , 
verification and adds a substantial number of verification capabilities to Sys- 
capability temVerilog. These testbench enhancements are covered in the 
forthcoming companion book, SystemVerilog for Verification. 

SystemVerilog At the time this book was written, Accellera was defining another 
3. la will be update to the SystemVerilog standard, with a target release for May 
donated to the 0 f 2004. This release will be called SystemVerilog 3.1a. This ver- 
IEEE s j on w jii a( j(i additional modeling and verification capabilities to 
SystemVerilog. Accellera has announced its intent to donate ver- 
sion 3.1a to the IEEE for integration into the IEEE 1364 Verilog 
standard. 

SystemVerilog SystemVerilog began with a version number of 3.0 to show that 
is the third SystemVerilog is the third major generation of the Verilog lan- 
generationof guage. Verilog- 1995 is the first generation, which represents the 
Verilog standardization of the original Verilog language defined by Phil 
Moorby in the early 1980s. Verilog-2001 is the second major gen- 
eration of Verilog, and SystemVerilog is the third major generation. 
Appendix B of this book contains more details on the history of 
hardware descriptions languages, and the evolution of Verilog that 
led up to SystemVerilog. 

Obtaining the Accellera SystemVerilog LRM 

The latest released version of the Accellera SystemVerilog Lan- 
guage Reference Manual (LRM) is available as a PDF document at 
the Accellera web site, www.accellera.org. It can also be obtained 
at www.systemverilog.org. 

1.1.2 Donations to SystemVerilog 

The primary technology donations that make up SystemVerilog 
include: 
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SystemVerilog 
comes from 
several 
donations 



SUPERLOG 
was donated by 
Co-Design 



OpenVERA and 
DirectC were 
donated by 
Synopsys 



SystemVerilog 
is backward 
compatible with 
Verilog 



• The SUPERLOG Extended Synthesizable Subset (SUPERLOG 
ESS), from Co-Design Automation 

• The OpenVERA™ verification language from Synopsys 

• PSL assertions (which began as a donation of Sugar assertions 
from IBM) 

• OpenVera Assertions (OVA) from Synopsys 

• The DirectC and coverage Application Programming Interfaces 
(APIs) from Synopsys 

• Separate compilation and Sreadmem extensions from Mentor 
Graphics 

In 2001, Co-Design Automation (which was acquired by Synopsys 
in 2002) donated to Accellera the SUPERLOG Extended Synthe- 
sizable Subset in June Of 2001. This donation makes up the major- 
ity of the modeling enhancements in SystemVerilog. Accellera then 
organized the Verilog++ committee, which was later renamed the 
SystemVerilog committee, to review this donation, and create a 
standard set of enhancements for the Verilog HDL. Appendix B 
contains a more complete history of the SUPERLOG language. 

In 2002, Synopsys donated OpenVERA testbench, OpenVERA 
Assertions (OVA), and DirectC to Accellera, as a complement to 
the SUPERLOG ESS donation. These donations significantly 
extend the verification capabilities of the Verilog language. 

The Accellera SystemVerilog committee also specified additional 
design and verification enhancements to the Verilog language that 
were not part of these core donations. 

Two major goals of the SystemVerilog committee within Accellera 
were to maintain lull backward compatibility with the existing Ver- 
ilog HDL, and to maintain the general look and feel of the Verilog 
HDL. 



1.2 Key SystemVerilog enhancements for hardware design 



The following list highlights some of the more significant enhance- 
ments SystemVerilog adds to the Verilog HDL for the design and 
verification of hardware: This list is not intended to be all inclusive 
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of every enhancement to Verilog that is in SystemVerilog. This list 

just highlights a few key features. 

• A unified assertion language for both simulation and formal veri- 
fication 

• Object oriented C++ like classes, with encapsulation, inheritance, 
and polymorphism 

• Interfaces to encapsulate communication and protocol checking 
within a design 

• Special program blocks and clocking domains for defining race 
free test programs 

• Constrained random number generation 

• C like data types, such as int 

• User-defined types, using the C typedef 

• Enumerated types 

• Typecasting 

• Structures and unions, as in C 

• Strings, dynamic arrays, associative arrays and lists 

• External compilation-unit scope declarations 

• ++, — , += and other assignment operators 

• Pass by reference to tasks, functions and modules 

• Semaphore and mailbox inter-process communication and syn- 
chronization 

• A Direct Programming Interface (DPI) to allow SystemVerilog 
to directly call C functions, and for C functions to directly call 
Verilog functions, without the complex Verilog Programming 
Language Interface (PLI) 



1.3 Summary 



SystemVerilog unifies several proven hardware design and verifi- 
cation languages, in the form of extensions to the Verilog HDL. 
These extensions provide powerful new capabilities for modeling 
hardware at the RTL, system and architectural levels, along with a 
rich set of features for verifying model functionality. 




Chapter 2 

SystemVerilog Literal Values 
and Built-in Data Types 



OystemVerilog extends Verilog’s built-in data types and 
O enhances how literal values can be specified. This chapter 
explains these enhancements and offers recommendations on 
proper usage. A number of small examples illustrate these enhance- 
ments in context. Subsequent chapters contain other examples that 
utilize SystemVerilog’s enhanced data types and literal values. The 
next chapter covers another important enhancement to data types, 
user-defined types. 

The enhancements presented in this chapter include: 

• Enhanced literal values 

• ‘define text substitution enhancements 

• External compilation-unit scope declarations 

• Time values 

• New data types 

• Signed and unsigned types 

• Variable initialization 

• Static and automatic variables 



• Casting 

• Constants 
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2.1 Enhanced literal value assignments 



filling a vector In the Verilog language, a vector can be easily filled with all zeros, 
with a literal all Xs (unknown), or all Zs (high-impedance). 
value 

reg [127:0] data; 



data = 


0; 


u 


fills 


data 


with 


128 


bits 


of 


zero 


data = 


■bz; 


// 


fills 


data 


with 


128 


bits 


of 


Z 


data = 


•bx; 


n 


fills 


data 


with 


128 


bits 


of 


X 



However, Verilog does not provide a convenient mechanism to fill 
a vector with all ones without using a literal value with all bits set to 
one, or using operators such as the replicate operator, a ones com- 
plement operator, or a twos complement operator. The following 
examples illustrate these styles, showing ways to assign a 128 bit 
vector to all ones: 

data_bus=128 ' hFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF; 

data__bus = {l28{l'bl}}; // replicate operation 

data_bus = ~0; // ones complement operation 

data_bus = -1; // twos complement operation 

special literal SystemVerilog enhances assignments of a literal value in two ways. 
value for filling a First, a simpler syntax is added, that allows specifying the fill value 
vector without having to specify a radix of binary, octal or hexadecimal. 
Secondly, the fill value can also be a logic 1. The syntax is to spec- 
ify the value with which to fill each bit, preceded by an apostrophe 
( 1 ), which is sometimes referred to as a "ticK\ Thus: 

• '0 fills all bits on the left-hand side with 0 

• ' l fills all bits on the left-hand side with 1 

• 'z or ' z fills all bits on the left-hand side with z 

• ’x or 'X fills all bits on the left-hand side with x 

Note that the apostrophe character ( ■ ) is not the same as the grave 
accent ( " ), which is sometimes referred to as a "back tick”. 

Using SystemVerilog, a vector of any width can be filled with all 
ones without hard coding the width of the value to be assigned, or 
using operations. 
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data_bus = '1; //set all bits of data_bus to 1 

literal values This enhancement to the Verilog language simplifies writing mod- 
scale with the els that work with very large vector sizes. The enhancement also 
size of the left - makes it possible to code models that automatically scale to new 
hand side vector vector sizes without having to modify the logic of the model. This 
automatic scaling is especially useful when using initializing vari- 
ables that have parameterized vector widths. 



2.2 ' define enhancements 



SystemVerilog extends the ability of Verilog’s 'define text sub- 
stitution macro by allowing the macro text to include certain special 
characters. 

2.2.1 Including backslashes in the macro text 

The Verilog-2001 standard added the ability to continue a 'define 
macro definition onto a new line by placing a backslash ( \ ) at the 
end of a line. There is no way in Verilog, however, to have a back- 
slash included as part of the text that is substituted by the macro. 

SystemVerilog allows the normal meaning of the backslash to be 
ignored by preceding the backslash with a grave accent ( ' ), some- 
times called a “back tick”. In the following example, a macro text is 
created that includes two backslash characters. The macro text is 
used to represent a hierarchy path that contains escaped names. 

'define reset test . ' \586_top . '\reset- 

initial 

'reset = 1; 

In this example, the macro ' reset will expand to: 
initial 

test . \586_top .\reset- = 1; 

2.2.2 Including quotes in the macro text 

Verilog allows the quotation mark ( " ) to be used in a 'define 
macro, but the text within the quotation marks became a literal 
string. This means that in Verilog, it is not possible to create a 



' \ allows a 
backslash in the 
macro text 
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string using text substitution macros where the string contained 
embedded arguments. 

' " allows a SystemVerilog allows arguments to be inside a macro text string by 
quote in the preceding the quotation marks that form the string with a grave 
macro text accen t ( % ). The example below defines a text substitution macro 
that represents a complete $di splay statement. The string to be 
printed contains a %h format argument. The substituted text will 
contain a text string that prints a message, including the name and 
logic value of the argument to the macro. The %h within the string 
will be correctly interpreted as a format argument. 

"define print (x) \ 

$display (" "variable x = %h"", x) 

"print (data) ; 

In this example, the macro 'print ( ) will expand to: 

$display( "variable data = %d" , data); 



2.2.3 Constructing identifier names from macros 

Using Verilog 'define, it is not possible to construct an identifier 
name by concatenating two or more text macros together. The prob- 
lem is that there will always be a white space between each portion 
of the constructed identifier name. 



' ' serves as a 
delimiter without 
a space in the 
macro text 



SystemVerilog provides a way to delimit an identifier name with- 
out introducing a white space, using two consecutive grave accent 
marks, i.e. ' '. This allows two or more names to be concatenated 
together to form a new name. 



One application for " is to simplify creating source code where a 
set of similar names are needed several times, and an array cannot 
be used. In the following example, a 2-state bit variable and a 
wand net need to be defined with similar names, and a continuous 
assignment of the variable to the net. The variable allows local pro- 
cedural assignments, and the net allows wired logic assignments 
from multiple drivers, where one of the drivers is the 2-state vari- 
able: 



In source code without text substitution, these declarations might 
be: 
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bit d00_bit; wand 
bit d01_bit; wand 

bit d62_bit; wand 
bit d63_bit; wand 



d00_net = dOO_bit; 
d01_net = d01_bit; 

d62__net = d62_bit; 
d63_net = d63_bit; 



Using the SystemVerilog enhancements to 'define, these declara- 
tions can be simplified as: 

'define TWO_STATE_NET (name) bit name"_bit; \ 
wand name''_net = name''_bit; 

' TWO_STATE_NET ( dO 0 ) 

'TWO STATE NET(dlO) 



' TWO__STATE_NET ( d6 2 ) 
'TWO STATE NET (d63 ) 



2.3 External compilation unit declarations 



Verilog requires In Verilog, declarations of variables, nets, tasks and functions must 
local declared within a module, between the module.. .endmodule key- 
declarations words. The objects declared within a module are local to the mod- 
ule. For modeling purposes, these objects should be referenced 
within the module in which they are declared. Verilog also allows 
hierarchical references to these objects from other modules for ver- 
ification purposes, but these cross-module references do not repre- 
sent hardware behavior, and are not synthesizable. 

SystemVerilog SystemVerilog adds a concept called a compilation unit to Verilog. 
has compilation A compilation unit is all source files that are compiled at the same 
units time. Compilation units provide a means for software tools to sepa- 
rately compile sub-blocks of an overall design. A sub-block might 
comprise a single module or multiple modules. The modules might 
be contained in a single file or in multiple files. A sub-block of a 
design might also contain interface blocks (presented in Chapter 9) 
and testbench program blocks (covered in the forthcoming compan- 
ion book, SystemVerilog for Verification ). 

compilation-unit SystemVerilog extends Verilog’s declaration space by allowing 
scopes contain declarations to be made outside of module, interface and program 
external block boundaries. These external declarations are in a compilation- 
declarations un if scope , and are visible to all modules that are compiled at the 
same time. 
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The compilation-unit scope can contain: 

• Time unit and precision declarations 

• Variable declarations 

• Net declarations 

• Constant declarations 

• User-defined data types, using typedef , enum or class 

• Task and function definitions 

The following example illustrates external declarations of a con- 
stant, a variable, a user-defined type, and a function. 

Example 2-1: External declarations in the compilation-unit scope 

/★★★★★a************* External declarations *******************/ 
parameter VERSION = "1.2a"; // external constant 

reg resetN =1; // external variable (active low) 

typedef struct packed { // external user -defined type 

reg [31:0] address; 
reg [31:0] data; 
reg [ 7:0] opcode; 

} instruct ion_word_t ; 

function automatic int log2 (input int n) ; // external function 

if (n <=1) return(l); 
log2 = 0; 

while (n > 1) begin 
n = n/2 ; 
log2++; 

end 

return (log2) ; 
endfunction 

j -k ******************* * module definition *********************/ 
// external declaration is used to define port types 
module register (output instruction_word_t q, 

input instruct ion_word_t d, 

input wire clock ) ; 

always @(posedge clock, negedge resetN) 

if (! resetN) q <= 0; // use external reset 

else q <= d; 
endmodule 
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External compilation-unit scope declarations are not global 

A declaration in the compilation-unit scope is not the same as a glo- 
bal declaration. A true global declaration, such as global variable or 
function, would be shared by all modules that make up a design, 
regardless of whether or not source files are compiled separately or 
at the same time. 

SystemVerilog’s compilation-scope only exists for source files that 
are compiled at the same time. Each time source files are compiled, 
a compilation-unit scope is created that is unique to just that compi- 
lation. For example, if module CPU and module controller both 
reference an externally declared variable called reset, then two 
possible scenarios exist: 

• If the two modules are compiled at the same time, there will be a 
single compilation-unit scope. The externally declared reset 
variable will be common to both modules. 

• If each module were compiled separately, then there would be 
two compilation-unit scopes, with two different reset variables. 

To create the affect of a global declaration using SystemVerilog’s 
compilation unit, all source files that share the declaration must be 
compiled at the same time, as a single compilation unit. 

SystemVerilog packages 

At the time this book was written, a proposal was under consider- 
ation to add a package construct to SystemVerilog. The proposed 
package would contain the same types of declarations as a compila- 
tion-unit scope. However, if two separate compilations use the 
same package definition, then variables, tasks and functions that are 
declared within the package will be shared by each compilation. 
Using packages, global declarations can be created regardless of 
whether source files are compiled at the same time or separately. In 
addition, specific portions of a design can use different packages, 
enabling unique external declarations regardless of how source files 
are compiled. For more information on SystemVerilog packages, 
refer to the Accellera Standard Organization’s web site for the lat- 
est release of the SystemVerilog standard (see page xxvii of the 
Preface details on obtaining the SystemVerilog LRM). 
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2.3.1 Synthesis guidelines 

The synthesizable constructs that can be declared within the compi- 
lation-unit scope (external to all module and interface definitions) 
are: 

• typedef user-defined type definitions 

• Automatic functions 

• Automatic tasks 

9 parameter and localparam constants 

use external An important usage of the compilation-unit scope is to create user- 
declarations for defined types that can be used by several modules in a design. User- 
user-deftned defined types are defined using typede£, and are discussed in 
types greater detail in the next chapter, Chapter 3. 

User-defined types defined in the compilation-unit scope are syn- 
thesizable. typede£ declarations do not allocate storage. The 
actual storage is allocated when variables are declared from a user- 
defined type. For synthesis, these variables must be declared within 
a module or interface. 

external tasks When a module references a task or function that is defined in the 
and functions compilation-unit scope, Synthesis will duplicate the task or func- 
must be tion code and treat it as if it had been defined within the module. To 
automatic b e synthesizable, tasks and functions defined in the compilation- 
unit scope must be declared as automatic, and cannot contain 
static variables. This is because storage for an automatic task or 
function is effectively allocated each time it is called. Thus, each 
module that references an automatic task or function in the compi- 
lation-unit scope sees a unique copy of the task or function storage 
that is not shared by any other module. This ensures that the simula- 
tion behavior of the pre-synthesis reference to the compilation-unit 
scope task or function will be the same as post-synthesis behavior, 
where the functionality of the task or function has been imple- 
mented within the module. 

A parameter constant defined within the compilation-unit scope 
cannot be redefined, since it is not part of a module instance. Syn- 
thesis treats constants declared in the compilation-unit scope as lit- 
eral values. 
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2.3.2 SystemVerilog identifier search rules 

Declarations in the compilation-unit scope can be referenced any- 
where in the hierarchy of modules that are part of the compilation 
unit. 



the compilation - SystemVerilog defines a simple and intuitive search rule for when 
unit scope is referencing an identifier: 
second in the 

search order 1 . First, search for local declarations, as defined in the IEEE 1364 
Verilog standard. 

2. Second, search for declarations in the compilation-unit scope. 

3. Third, search for declarations within the design hierarchy, fol- 
lowing IEEE 1364 Verilog search rules. 

The SystemVerilog search rules ensure that SystemVerilog is fully 
backward compatible with Verilog. 



2.3.3 Source code order 




Identifiers and type definitions must be declared before being 
referenced. 



Variables and nets in the compilation-unit scope 



undeclared 
identifiers have 
an implicit data 
type 



There is an important consideration when using external declara- 
tions. Verilog supports implicit data types, where, in specific con- 
texts, an undeclared identifier is assumed to be a net data type 
(typically a wire type). Verilog requires the data type of identifiers 
to be explicitly declared before the identifier is referenced when the 
context will not infer an implicit data type, or when a type other 
than the default net data type is desired. 



external 
declarations 
must be defined 
before use 



This implicit data type rule affects the declaration of variables and 
nets in the compilation-unit scope. Software tools must encounter 
the external declaration before an identifier is referenced. If not, the 
name will be treated as an undeclared identifier, and follow the 
Verilog rules for implicit data types. 



The following example illustrates how source code order can affect 
the usage of a declaration external to the module. This example will 
not generate any type of compilation or elaboration error. Since the 
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reference to the signal called parity comes before the external 
declaration for the signal, software tools will automatically infer 
parity is an implicit net data type local to the module. 

module parity_check (input wire [63:0] data ); 

assign parity = A data; // parity is an 
endmodule // implicit local net 

reg parity; // external declaration is not 
// used by module parity_check 

User-defined types in the compilation-unit scope 

external user - An important usage of the compilation-unit scope is to define new 
defined types data types using SystemVerilog’s typedef construct. By defining 
a new data type external to all modules and interfaces, every mod- 
ule and interface, anywhere in the compilation unit, can use the 
user-defined type. User-defined types are covered in more detail in 
Chapter 3. 

SystemVerilog allows user-defined types to be passed through 
module ports. To do this, the port type must be declared as the user- 
defined type. This requires that the new type be declared outside the 
module’s boundaries, so that compilers can see the type definition 
before it is used as a port type. Example 2-1, shown earlier on page 
12, illustrates declaring a module port as a user-defined type. 

2.3.4 Coding guidelines for external declarations 

Place shared external declarations in a separate file 

Any declaration not within a module, interface or program bound- 
ary is in the compilation-unit scope. It is syntactically permissible 
for these external declarations to be made in any or all of the source 
code files that make up a compilation unit. However, if an external 
declaration, such as a user-defined type, is to be used by more than 
one module, file order dependencies can result if care is not taken. 
It is a common practice to place each module definition in a sepa- 
rate file. For example, module CPU might be in file CPU.v, and 
module controller might be in file controller . v. If an exter- 
nal declaration that is used by both modules in contained in the 
CPU.v file, then the controller. v file can only be compiled at 
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the same time as CPU.v, and CPU. v must be read in first by com- 
piler. 

place external By placing external definitions that are to be shared by multiple 
declarations in modules in a separate file, each module can be compiled indepen- 
separate files dently of other modules, with just the external definitions file. 

Keep external declarations in a common file. 

TIP 

In order to easily debug and maintain design models, it is recom- 
mended that shared external declarations be kept together in a com- 
mon file. This file should only contain external declarations, and 
not any design modules. If a design is partitioned in such a way that 
only certain partitions require access to specific compilation-unit 
scope declarations, then separate external definition files can be 
created for each design partition. 

Avoid excessive compilation unit declarations 

The compilation-unit scope should be used conservatively. If too 
many declarations are made externally, the compilation-unit scope 
name space can become cluttered and difficult to maintain. This can 
easily occur if different members of a design team each make exter- 
nal declarations without consulting other members of the team, and 
then all the files from the different team members are compiled 
together as a single compilation unit. Name conflicts can also occur 
if third party models, such as IP models, make external declarations 
that happen to use the same names as other external declarations in 
the compilation unit. 

limit compilation It is recommended that the compilation-unit scope be primarily lim- 
unit declarations ited for defining user-defined types that will be used by many dif- 
to user-defined ferent modules in a design, or that need to be used in module port 
types and declarations. Constants that will be used by many modules can also 
constants b e d ec i are( j externally, rather than in each module. 

Make external names unique 

In the typical design project, models are developed by many differ- 
ent engineers. Some models will be written by engineers within the 
design team. Other models are written by engineers outside of the 
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design team, such as an intellectual property (IP) model supplier. It 
is possible to have problems with name collisions in the compila- 
tion-unit scope name space if care is not taken to create unique 
external names. One suggestion is that the first two or three letters 
of each external name should indicate the name of the product or 
project. This will help ensure that external names created within a 
design team will be unique from external names defined by other 
sources. 



2.4 Simulation time units and precision 



The Verilog language does not specify time units as part of time 
values. Time values are simply relative to each other. A delay of 3 
is larger than a delay of 1, and smaller than a delay of 10. Without 
time units, the following statement, a simple clock oscillator that 
might be used in a testbench, is somewhat ambiguous: 

forever #5 clock = -clock; 

What is the period of this clock? Is it 10 picoseconds? 10 nanosec- 
onds? 10 milliseconds? There is no information in the statement 
itself to answer this question. One must look elsewhere in the Ver- 
ilog source code to determine what units of time the #5 represents. 



2.4.1 Verilog’s timescale directive 



Verilog specifies Instead of specifying the units of time with the time value, Verilog 
time units to the specifies time units as a command to the software tool, using a 
software tool * timescale compiler directive. This directive has two compo- 
nents: the time units, and the time precision to be used. The preci- 
sion component tells the software tool how many decimal places of 
accuracy to use. 



In the following example, 

'timescale Ins / lOps 

the software tool is instructed to use time units of 1 nanosecond, 
and a precision of 10 picoseconds, which is 2 decimal places, rela- 
tive to 1 nanosecond. 




Chapter 2: SystemVerilog Literal Values and Built-in Data Types 



19 



multiple The 'timescale directive can be defined in none, one or more 
‘timescale Verilog source files. Directives with different values can be speci- 
directives fied for different regions of a design. When this occurs, the soft- 
ware tool must resolve the differences by finding a common 
denominator in all the time units specified, and then scaling all the 
delays in each region of the design to the common denominator. 

the ‘timescale A problem with the 'timescale directive is that the command is 
directive is file not bound to specific modules, or to specific files. The directive is a 
order dependent command to the software tool, and remains in effect until a new 
'timescale command is encountered. This creates a dependency 
on which order the Verilog source files are read by the software 
tool. Source files without a 'timescale directive are dependent 
on the order in which the file is read relative to previous files. 

In the following illustration, files A and C contain 'timescale 
directives that set the software tool’s time units and time precision 
for the code that follows the directives. File B, however, does not 
contain a ' timescale directive. 



compilation order 



'timescale lns/lns 

module A (...); 

nand #3 (...); 
endmodule 







File A 


□ 


r r 



module B (...); 

nand #5 (...); 
endmodule 



□ 


u 


L 


File B 


m 


r 



'timescale lms/lms 

module C (...)/ 




J 




File C 


nand #2 (...); 


endmodule 




nr 



Module B delays are in nanoseconds 

If the source files are read in the order of File A then B and then C, 
the 'timescale directive that is in effect when module B is com- 
piled is 1 nanosecond units with 1 nanosecond precision. Therefore, 
the delay of 5 in module B represents a delay of 5 nanoseconds. 
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If the source files are read in by a compiler in a different order, 
however, the effects of the compiler directives could be different. 
The illustration below shows the file order as A then C and then B. 

compilation order 



'timescale Ins /Ins 




1 


module A (...); 


File A 


nand #3 (...); 


endmodule 


_ 


1 


r 



'timescale lms/lms 
module C (...) ; 
nand #2 (...) ; 




Li 


L 


File C 


endmodule 


□ 


n 


r 



module B (...); 

nand #5 (...); 
endmodule 



FileB 



J 



Module B delays are in milliseconds 



In this case, the % timescale directive in effect when module B is 
compiled is 1 millisecond units with 1 millisecond precision. 
Therefore, the delay of 5 represents 5 milliseconds. The simulation 
results from this second file order will be very different than the 
results of the first file order. 



2.4.2 Time values with time units 

time units SystemVerilog extends the Verilog language by allowing time units 
specified as part to be specified as part of the time value 
of the time value 

forever #5ns clock = -clock; 

Specifying the time units as part of the time value removes all 
ambiguity as to what the delay represents. The preceding example 
is a 10 nanoseconds oscillator (5 ns high, 5 ns low). 

The time units that are allowed are listed in the following table. 
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Table 2-1: SystemVerilog time units 



Unit 


Description 


s 


seconds 


ms 


milliseconds 


us 


microseconds 


ns 


nanoseconds 


ps 


picoseconds 


fa 


femtoseconds 


step 


the smallest unit of time being used by the software tool; 
restricted to the SystemVerilog testbench clocking domain 



No space is allowed between the time value and the time unit. 

When specifying a time unit as part of the time value, there can be 
no white space between the value and time unit. 

#3 . 2ps // legal 

#4.1 ps // illegal: no space allowed 




2.4.3 Module-level time unit and precision 

SystemVerilog allows the time units and time precision of time val- 
ues to be specified locally, as part of a module, interface or program 
block, instead of as commands to the software tool (interfaces are 
discussed in Chapter 9 of this book, and program blocks are pre- 
sented in the forthcoming companion book, SystemVerilog for Ver- 
ification). 

timeunitand In SystemVerilog, the specification of time units is further 
timeprecision as enhanced with the keywords timeunit and tlmepreclslon. 
part of module These keywords are used to specify the time unit and precision 
definition information within a module, as part of the module definition. 

module chip (...); 
timeunit Ins; 
timeprecision 10ps; 
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The timeunit and timeprecision keywords allow binding the 
unit and precision information directly to a module, interface or 
program block, instead of being commands to the software tool. 
This resolves the ambiguity and file order dependency that exist 
with Verilog’s 'timescale directive. 

The units that can be specified with the timeunit and timepre- 
cision keywords are the same as the units and precision that are 
allowed with Verilog’s 'timescale directive. These are the units 
that are listed in table 2-1 on page 21, except that the special step 
unit is not allowed. As with the 'timescale directive, the units 
can be specified in multiples of 1, 10 or 100. 




The timeunit and timeprecision statements must be 
specified immediately after the module, interface, or program 
declaration, before any other declarations or statements. 



timeunit and The specification of a module timeunit and timeprecision 
timeprecision must be the first statements within a module, appearing immedi- 
must be first ately after the port list, and before any other declarations or state- 
ments. Note that Verilog allows declarations within the port list. 
This does not affect the placement of the timeunit and timepre- 
cision statements. These statements must still come immediately 
after the module declaration. For example: 



module adder (input wire [63:0] a, b, 

output reg [63:0] sum, 

output reg carry) ; 

timeunit Ins; 
timeprecision lOps; 



2.4.4 Compilation-unit time units and precision 

external timeunit The timeunit and/or the timeprecision declaration can be 
and specified in the compilation-unit scope (described earlier in this 
timeprecision chapter, in section 2.3 on page 11). The declarations must come 
before any other declarations. A timeunit or timeprecision 
declaration in the compilation-unit scope applies to all modules, 
program blocks and interfaces that do not have a local timeunit or 
timeprecision declaration, and which were not compiled with 
the Verilog 'timescale directive in effect. 
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At most, one timeunit value and one timeprecision value can 
be specified in the compilation-unit scope. There can be more than 
one timeunit or timeprecision statements in the compilation- 
unit scope, as long as all statements have the same value. 

Time unit and precision search order 

time unit and With SystemVerilog, the time unit and precision of a time value can 
precision search be specified in multiple places. SystemVerilog defines a specific 
order search order to determine a time value’s time unit and precision: 

• If specified, use the time unit specified as part of the time value. 

• Else, if specified, use the local time unit and precision specified 
in the module, interface or program block. 

• Else, if the module or interface declaration is nested within 
another module or interface, use the time unit and precision in 
use by the parent module or interface. Nested module declara- 
tions are discussed in Chapter 8 and interfaces are discussed in 
Chapter 9. 

• Else, if specified, use the 'timescale time unit and precision in 
effect when the module was compiled. 

• Else, if specified, use the time unit and precision defined in the 
compilation-unit scope. 

• Else, use the simulator’s default time unit and precision. 

backward This search order allows models using the SystemVerilog exten- 
compatibility sions to be fully backward compatible with models written for Ver- 
ilog. 

The following example illustrates a mixture of delays with time 
units, timeunit and timeprecision declarations at both the 
module and compilation-unit scope levels, and 'timeprecision 
compiler directives. The comments indicate which declaration 
takes precedence. 

Example 2-2: Mixed methods of declaring time units and time precision 

timeunit Ins; // external time unit and precision 

timeprecision Ins; 



module my_chip ( ... ) ; 
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timeprecision lps; // local precision (priority over external) 

always ©(posedge data_request) begin 

#2.5 send_j?acket ; // uses external units & local precision 

#3. 75ns check_crc; // specific units take precedence 

end 

task send__packet ( ) ; 

endtask 

task check_crc ( ) ; 

endtask 

endxnodule 

"timescale lps/lps // directive takes precedence over external 
module FSM ( ... ); 

timeunit Ins; // local units take priority over directive 

always @ (State) begin 

#1.2 case (State) // uses local units & timescale precision 
WAIT: #20ps ...; // specific units take precedence 



end 

endmodule 



2.5 SystemVerilog data types 



2.5.1 Verilog data types 

Verilog’s The Verilog language has hardware-centric net data types. These 
hardware data types have special simulation and synthesis semantics to repre- 
data types sent the behavior of real connections in a chip or system. 

• The Verilog reg and integer data types have 4 logic values for 
each bit: 0, 1, Z and X. 

• The Verilog wire, wor, wand, and other net types have 120 val- 
ues for each bit (4-state logic plus multiple strength levels) and 
special wired logic resolution functions. 
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These multi-value data types are necessary for gate-level simula- 
tion accuracy, but are not required at the system and RTL level of 
modeling, where most logic can be represented using only 2-state 
values. At these abstract modeling levels, tri-state busses are the 
only place 4-state values are required. Multiple module output or 
inout ports connected together are the only time net resolution is 
needed. 

2.5.2 SystemVerilog data types 

SystemVerilog’s SystemVerilog adds several new 2-state data types, intended for 
2-state modeling at the abstract levels or RTL and system level. These data 
datatypes types include: 

• bit — a 1-bit 2-state integer 

• byte — an 8-bit 2-state integer, similar to a C char 

• short in t — a 16-bit 2-state integer, similar to a C short 

• int — a 32-bit 2-state integer, similar to a C int 

• longint — a 64-bit 2-state integer, similar to a C longlong 

SystemVerilog also adds three other special types for more efficient 
system-level modeling and for verification testbenches: 

• void — used to define functions that do not have a return value, 
or for ignoring a function return using casting 

• shortreal — a 32-bit single-precision floating point, the same 
as a C float 

• logic — a 1-bit 4-state integer with no strength levels, equiva- 
lent to the Verilog reg data type 

The 4-state logic data type 

the Verilog reg The Verilog language uses the reg data type as a general purpose 
data type variable for modeling hardware behavior in initial and always 
procedural blocks. The keyword reg is a misnomer that is often 
confusing to new users of the Verilog language. The term “reg” 
would seem to imply a hardware “register”, typically built with 
some form of sequential logic flip-flops. In actuality, there is no 
correlation whatsoever between using a reg variable and the hard- 
ware that will be inferred. It is the context in which the reg variable 
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is used that determines if the hardware represented is combinational 
logic or sequential logic. 

the logic SystemVerilog uses the more intuitive logic keyword to represent 
datatype a general purpose, hardware-centric variable. Semantically, the 
replaces reg logic data type is identical to the reg data type. The two key- 
words are synonyms, and can be used interchangeably. Like the 
Verilog reg data type, the logic data type can store 4-state logic 
values (0, 1, Z and X), and vectors of any width can be defined 
using the logic type. Some example declarations using the logic 
data type are: 

logic resetN; // a 1-bit wide 4 -state variable 

logic [63:0] data; // a 64-bit wide variable 

logic [0:7] array [0:255]; // an array of 8-bit 

variables 

Because the keyword logic does not convey a false implication of 
the type of hardware represented, the logic data type is a more 
intuitive keyword choice for describing hardware when 4-state 
logic is required. In the subsequent examples in this book, the 
logic data type is used in place of the Verilog reg data type 
(except when the example illustrates pure Verilog code, with no 
SystemVerilog enhancements). 

The 2-state bit data type 

The bit type has The reg or logic data types are used for modeling hardware 
2-state values behavior in procedural blocks. These data types store 4-state logic 
values, 0, 1, Z and X. At the RTL and system levels of modeling, 
logic values of Z and X are seldom required. Synthesis and formal 
verification tools do not use X as a logic value, and only support the 
Z value for the specification of tri-state outputs. 

the 2-state bit SystemVerilog adds a bit data type. Syntactically, the bit type 
data type can be can be used any place the Verilog reg or logic types can be used. 
used in place of However, the bit data type is semantically different, in that it only 
reg or logic type stores 2-state values of 0 and 1 . This makes the bit data type ideal 
for modeling hardware at the RTL and higher levels of abstraction. 

Variables of the bit data type are declared in the same way as reg 
and logic types. Declarations can be any vector width, from 1-bit 
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wide to the maximum size supported by the software tool. The 
IEEE 1364 Verilog standard defines that all compliant software 
tools should support vector widths of at least 2 16 bits wide. 

bit resetN; // a 1-bit wide 2-state variable 

bit [63:0] data; // a 64-bit 2-state variable 

bit [0:7] array [0:255]; // an array of 8-bit 

2 -state variables 

2.5.3 Synthesis guidelines 

2-state types The 4-state logic data type and the 2-state bit, byte, shortint, 
synthesize the int, and longint data types are synthesizable. Synthesis compil- 
same as 4-state ers treat 2-state and 4-state types the same way. The use of 2-state 
types d a t a types primarily affects simulation. 

synthesis 2-state data types begin simulation with a default value of logic 
ignores the value of 0. Synthesis ignores this default initial value. The post- 
default initial synthesis design realized by synthesis is not guaranteed to power up 
value of 2-state with zeros in the same way that pre-synthesis models using 2-state 
types data types will appear to power up. 

Section 7.2 on page 177 presents additional modeling consider- 
ations regarding the default initial value of 2-state data types. 



2.6 Relaxation of data type rules 

Verilog restricts In Verilog, there are strict semantic restrictions regarding where 
usage of variable data types such as reg can be used, and where net data 
variables and types such as wire can be used. The decision of when to use reg 
nets and when to use wire is based entirely on the context of how the 
signal is used within the model. The general rule of thumb is that a 
variable must be used when modeling using initial and always 
procedural blocks, and a net must be used when modeling using 
continuous assignments, module instances or primitive instances. 

These restrictions on data type usage are often frustrating to engi- 
neers who are first learning the Verilog language. The restrictions 
also make it difficult to evolve a model from abstract system level 
to RTL to gate level because, as the context of the model changes, 
the data type declarations may also have to be changed. 
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SystemVerilog greatly simplifies determining the proper data type 
to use in a model, by relaxing the rules of where variables can be 
used. With SystemVerilog, any variable data type can receive a 
value in any one of the following ways, but no more than one of the 
following ways: 

• Be assigned a value from any number of initial or always 
procedural blocks (the same rule as in Verilog). 

• Be assigned a value from a single always_comb, always_f f or 
always_latch procedural block. These SystemVerilog proce- 
dural blocks are discussed in Chapter 5. 

• Be assigned a value from a single continuous assignment state- 
ment. 

• Be driven to a value from a single module or primitive output or 
inout port. 

most signals These relaxed rules for using variables allow most signals in a 
can be declared model to be declared as a variable type, such as bit or logic. It is 
as logic or bit not necessary to first determine the context in which that signal will 
be used. The data type of the signal does not need to be changed as 
the model evolves from system level to RTL to gate level. 

The following simple example illustrates the use of variables under 
these relaxed data type rules. 

Example 2-3: Relaxed usage of variables 

module compare (output bit It, eq # gt, 

input logic [63:0] a, b ); 

always @(a, b) 

if (a < b) It = I'bl; // procedural assignments 
else It = 1'bO; 

assign gt = (a > b) ; // continuous assignments 

comparator ul (eq, a, b) ; // module instance 

endmodule 

module comparator (output bit eq, 

input [63:0] a, b) ; 

always @(a, b) 
eq = (a==b) ; 

endmodule 



SystemVerilog 
relaxes 
restrictions on 
using variables 
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Restrictions on variables can prevent design errors 

Variables cannot be driven by multiple sources. 

SystemVerilog It is important to note that though SystemVerilog allows variables 
restrictions on to be used in places where Verilog does not, SystemVerilog does 
using variables still have some restrictions on the usage of variables. 

SystemVerilog makes it an error to have multiple output ports or 
multiple continuous assignments write to the same variable, or to 
combine procedural assignments with continuous assignments or 
output drivers on the same variable. 

It is also illegal to write to an automatic variable from a continuous 
assignment or a module output. Only static variables can be contin- 
uously assigned or connected to an output port. Static variables are 
required because the variable must be present throughout simula- 
tion in order to continuously write to it. Automatic variables do not 
necessarily exist the entire time simulation is running. 

The reason for this restrictions is because variable data types do not 
have built-in resolution functionality to resolve a final value when 
two or more devices drive the same output. Only the Verilog net 
data types, such as wire, wand (wire-and) and wor (wire-or), have 
built-in resolution functions. 




Example 2-4: Illegal use of variables 

module add_and_increment (output bit [63:0] sum, 

output bit carry, 

input bit [63:0] a, b ); 

always @(a, b) 

sum = a + b; // procedural assignment to sum 

assign sum = sum +1/ // ERROR! sum is already being 

// assigned a value 

look__ahead il (carry, a, b) ; // module instance drives carry 

overf low_check i2 (carry, a, b) ; // ERROR! 2nd driver of carry 

endmodule 

module look_ahead (output wire carry, // prototype 
input bit [63:0] a, b) ; 



endmodule 
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module overf low_check (output wire carry, // prototype 

input bit [63:0] a, b) ; 



endmodule 



Use variables for single-driver logic, and use nets for multi- 
driver logic. 

SystemVerilog’s relaxed rules for using variables, along with the 
restriction that variables cannot be driven by multiple outputs or 
continuous assignments, can be used to prevent design errors. 
Wherever a signal in a design should only have a single driver, a 
variable data type can be used. The single driver can be a proce- 
dural block, a continuous assignment, or an output port of a module 
or primitive. Should a second driver inadvertently be connected to 
the same signal, it will be detected as an error, because each vari- 
able can only have a single driver. 

SystemVerilog does permit a variable to be written to by multiple 
always procedural blocks, which can be considered a form of mul- 
tiple drivers. This condition must be allowed for backward compat- 
ibility with the existing Verilog language. Chapter 5 introduces 
three new types of always procedural blocks: always_comb, 
always_latch and always_ff. These new procedural blocks 
also have the restriction that a variable can only be assigned from 
one procedural block. This further enforces the checking that a sig- 
nal declared as a variable type only has a single driver. 

Only net data types can have multiple drivers, such as multiple con- 
tinuous assignments and/or connections to multiple output ports of 
module or primitive instances. Therefore, a signal in a design such 
as a data bus or address bus that can be driven from several devices 
should be declared as a Verilog net data type, such as wire. Bi- 
directional module ports, which can be used as both an input and an 
output, must also be declared as a net data type. 
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2.7 Signed and unsigned modifiers 



Verilog-1995 The first IEEE Verilog standard, Verilog-1995, had just one signed 
signed types data type, declared with the keyword integer. This data type has a 
fixed size of 32 bits in most, if not all, software tools that support 
Verilog. Because of this, and some limitations of literal numbers, 
Verilog-1995 was limited to doing signed operations on just 32-bit 
wide vectors. 

Verilog-2001 The IEEE Verilog-2001 standard added several significant 
signed types enhancements to allow signed arithmetic operations on any data 
type and with any vector size. The enhancement that affects data 
types is the ability to declare any data type as signed. This modi- 
fier overrides the default definition of unsigned data types in Ver- 
ilog. For example: 

reg [63:0] u; // unsigned 64 -bit variable 
reg signed [63:0] s; // signed 64 -bit variable 

SystemVerilog SystemVerilog adds new data types that are signed by default. 

signed and These signed types are: byte, shortint, int, and longint. Sys- 
unsigned types temVerilog provides a mechanism to explicitly override the signed 
behavior of these new data types, using the unsigned keyword. 

int s_int; // signed 32 -bit variable 

int unsigned u_int; // unsigned 32 -bit variable 

SystemVerilog’s signed declaration is not the same as C’s. 

The C language places the signed or unsigned keyword before 
the data type keyword. 

unsigned int u; /* C declaration */ 

Verilog places the signed keyword (Verilog does not have an 
unsigned keyword) after the data type declaration, as in: 

reg signed [31:0] s; // Verilog declaration 

SystemVerilog also places the signed or unsigned keyword after 
the data type keyword. This is consistent with Verilog, but different 
than C. 




int unsigned u; // SystemVerilog declaration 
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2.8 Static and automatic variables 



Verilog-1995 In the Verilog-1995 standard, all data types are static, with the 
data types are expectation that these data types are for modeling hardware, which 
static is also static in nature. 

Verilog-2001 The Verilog-2001 standard adds the ability to define variables in a 
adds automatic task or function as automatic, meaning that the variable storage is 
tasks and dynamically allocated by the software tool when required, and deal- 
functions located when no longer needed. Automatic variables — also referred 
to as dynamic variables — are primarily intended for representing 
verification routines in a testbench. The dynamic nature of auto- 
matic variables allows coding re-entrant tasks, so that a task can be 
called while a previous call of the task is still running. Automatic 
variables also allow coding recursive function calls, where a func- 
tion calls itself. Each time a task or function with automatic vari- 
ables is called, new variable storage is created. When the call exits, 
the storage is destroyed. 

In Verilog, automatic variables are declared by declaring the entire 
task or function as automatic. All variables in an automatic task or 
function are dynamic. 

The following example illustrates a balance adder that adds the ele- 
ments of an array together. The low address and high address of the 
array elements to be added are passed in as arguments. The function 
then recursively calls itself to add the array elements. In this exam- 
ple, the arguments lo and hi are automatic, as well as the internal 
variable mid. Therefore, each recursive call allocates new variables 
for that specific call. 

function automatic int b_add (int lo, hi) ; 
int mid = (lo + hi + 1) >> 1; 
if (lo + 1 != hi) 

return (b__add(lo, (mid-1) ) + b_add (mid, hi) ) ; 

else 

return (array [lo] + array [hi]); 
endfunction 

SystemVerilog SystemVerilog extends the ability to declare static and automatic 
adds static variables. SystemVerilog adds a static keyword, and allows any 
declarations variable to be explicitly declared as either static or automatic. 

This declaration is part of the variable declaration, and can appear 
within tasks, functions, begin.. .end blocks, or fork.. .join 
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blocks. Note that variables declared at the module level cannot be 
explicitly declared as static or automatic. At the module level, 
all variables are static. 

The following code fragment illustrates explicit automatic declara- 
tions in a static function: 

function int count_ones (input bit [31:0] data)/ 
automatic int i, count = 0; 
automatic bit [31:0] temp = data; 

for (1=0/ (temp/ i++) begin 
if (temp[0]) count += 1; 
temp >>= 1; 

end 

return (count) ; 
endfunction 

The next example illustrates an explicit static variable in an auto- 
matic task. This example checks a value for errors, and increments 
an error count each time an error is detected. If the error_count 
variable were automatic as is the rest of the task, it would be recre- 
ated each time the task was called, and only hold the error count for 
that call of the task. As a static variable, it retains its value from one 
call of the task to the next, and can thereby keep a running total of 
all errors. 

typedef struct packed {...} packet_t; 
task automatic check_results 

(input packet_t sent, received) ; 
static int error_count ; 
if (sent i== received) error__count++ ; 
endtask 

backward The defaults for storage in SystemVerilog are completely backward 
compatibility compatible with Verilog. In modules, begin.. .end blocks, 
fork.. .join blocks, and non-automatic tasks and functions, all 
storage defaults to static, unless explicitly declared as automatic. 
This default behavior is the same as the static storage in Verilog 
modules, begin.. .end or fork.. .join blocks and non-automatic 
tasks and functions. If a task or function is declared as automatic, 
the default storage for all variables will be automatic, unless explic- 
itly declared as static. This default behavior is the same as with 
Verilog, where all storage in an automatic task or function is auto- 
matic. 
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2.8.1 Static and automatic variable initialization 

Verilog variable in-line variable initialization 

Verilog only permits in-line variable initialization for variables 
declared at the module level. Variables declared in tasks, functions 
and begin.. .end or fork.. .join blocks cannot have an initial 
value specified as part of the variable declaration. 

SystemVerilog in-line variable initialization 

initializing static SystemVerilog extends Verilog to allow variables declared within 
and automatic tasks, functions, begin.. .end blocks, fork.. .join blocks, or the 
variables compilation-unit scope to be declared with in-line initial values. 

SystemVerilog also defines when the initialization will take place 
for static and automatic variables, as described in the following 
paragraphs. 

Initializing variables in modules 

A variable declared at the module level will always be static. The 
in-line initial value will be assigned one time, prior to simulation 
time zero. 

module decoder (...); 

int count =0; // only initialized once 

// at beginning of simulation 

always @(data) begin 

end 

endmodule 

Initializing variables within blocks 

variables in SystemVerilog allows local variables declared within a 
blocks can be begin.. .end block or fork... join block to be declared with an in- 
initialized line initial value. 

module decoder (...); 

always @(data) begin: decode Jblock 

int count =0; // initialized once 
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automatic int i= 1; // initialized 

// each time called 



end 

endmodule 

static variables If a variable within a block is not declared as automatic, it is 
are initialized assumed to be static. The in-line initial value will be assigned one 
once time, prior to simulation time zero. This is the same behavior as 
variables declared at the module level. 

automatic If a variable within a begin.. .end or fork... join block is declared 
variables are as automatic, the variable will be re-initialized each time the 
initialized each block is entered. 
time created 

Initializing variables in static tasks and functions 

A variable declared in a non-automatic task or function will be 
static by default. An in-line initial value will be assigned one time, 
before the start of simulation. Calls to the task or function will not 
re-initialize the variable. 

The following example will not work correctly. The count_ones 
function is static, and therefore all storage within the function is 
also static, unless expressly declared as automatic. In this exam- 
ple, the variable count will have an initial value of 0 the first time 
the function is called. However, it will not be re-initialized the next 
time it is called. Instead, the static variable will retain its value from 
the previous call, resulting in an erroneous count. The static vari- 
able temp will have a value of 0 the first time the function is called, 
rather than the value of data. This is because in-line initialization 
takes place prior to time zero, and not when the function is called. 

function int count_ones (input bit [31:0] data); 
int i; 

count =0; // static: only initialized once 

bit [31:0] temp = data; 

for ( i = 0 ; (temp; i++) begin 

if (temp[0]> count = count + 1; 
temp = temp >> 1; 

end 

return (count) ; 
endf unction 
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A variable explicitly declared as automatic in a non-automatic 
task or function will be dynamically created each time the task or 
function is entered, and destroyed each time the task or function 
exits. An in-line initial value will be assigned each time the block is 
entered. The following version of the count_ones function will 
work correctly, because the automatic variables count and temp 
are initialized each time the function is called. 

function int count_ones (input bit [31:0] data); 
int i; 

automatic int count =0; // initialized each 

// time called 

automatic bit [31:0] temp = data; 

for (i=0; |temp; i++) begin 

if (temp[0]) count = count + 1; 
temp = temp >> 1; 

end 

return (count) ; 
endfunction 

Initializing variables in automatic tasks and functions 

A variable declared in an automatic task or function will be auto- 
matic by default. Storage for the variable will be dynamically cre- 
ated each time the task or function is entered, and destroyed each 
time the task or function exits. An in-line initial value will be 
assigned each time the task or function is entered and new storage 
is created. 

static variables A variable can be explicitly declared as static in an automatic 
are initialized task or function will be created one time, and shared by all calls to 
once the task or function. An in-line initial value will be assigned one 
time, prior to the start of simulation, the same as with in-line vari- 
able initialization in a module, or in a static task or function. Subse- 
quent calls to the task or function will not re-initialize the variable. 

typedef struct packed { . . . } packet_t; 
task automatic check__results 

(input packet_t sent, received) ; 
static int error_count = 0; 
if (sent !== received) error_count++ ; 
endtask 



automatic 
variables are 
initialized each 
time created 
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2.8.2 Synthesis guidelines for automatic variables 

The dynamic storage of automatic variables can be used both in 
verification testbenches and to represent hardware models. To be 
synthesized in a hardware model, the automatic variables should 
only be used to represent temporary storage that does not propagate 
outside of the task, function or procedural block. 




Static variable initialization is not synthesizable. Automatic 
variable initialization is synthesizable. 



Initialization of static variables is not synthesizable. In-line initial 
value assignments to static variables are ignored by synthesis. 

In-line initialization of automatic variables is synthesizable. The 
count_ones function example listed on earlier in this chapter, in 
section 2.8 on page 32, meets these synthesis criteria. The auto- 
matic variables count and temp are only used within the function, 
and the values of the variables are only used by the current call to 
the function. 

In-line initialization of variables declared with the const qualifier 
is also synthesizable. Section 2.1 1 on page 46 covers const decla- 
rations. 



2.8.3 Guidelines for using static and automatic variables 

The following guidelines will aid in the decision on when to use 

static variables and when to use automatic variables. 

• In an always or Initial block, use static variables if there is 
no in-line initialization, and automatic variables if there is an in- 
line initialization. Using automatic variables with in-line initial- 
ization will give the most intuitive behavior, because the variable 
will be re-initialized each time the block is re-executed. 

• If a task or function is to be re-entrant, it should be automatic. 
The variables also ought to be automatic, unless there is a spe- 
cific reason for keeping the value from one call to the next. As a 
simple example, a variable that keeps a count of the number of 
times an automatic task or function is called would need to be 
static. 
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• If a task or function represents the behavior of a single piece of 
hardware, and therefore is not re-entrant, then it should be 
declared as static, and all variables within the task or function 
should be static. 



2.9 Deterministic variable initialization 

2.9.1 Initialization determinism 

Verilog-1995 variable initialization 

In the original Verilog language, which was standardized in 1995, 
variables could not be initialized at the time of declaration, as can 
be done in C. Instead, a separate initial procedural block was 
required to set the initial value of variables. For example: 

integer i; // declare a variable named i 

integer j ; // declare a variable named j 

initial 

i = 5; // initialize i to 5 

initial 

j = i; // initialize j to the value of i 

The Verilog standard explicitly states that the order in which a soft- 
ware tool executes multiple initial procedural blocks is nonde- 
terministic. Thus, in the preceding example it cannot be determined 
whether j will be assigned the value of i before i is initialized to 5 
or after i is initialized. If, in the preceding example, the intent is 
that i is assigned a value of 5 first, and then j is assigned the value 
of i, the only deterministic way to model the initialization is to 
group both assignments into a single initial procedural block 
with a begin.. .end block. Statements within begin.. .end blocks 
execute in sequence, giving the user control the order in which the 
statements are executed. 

integer i; // declare a variable named i 

integer j ; // declare a variable named j 

initial begin 

i = 5; // initialize i to 5 

j = i; // initialize j to the value of i 

end 



Verilog-1995 
initialization can 
be 

nondeterministic 
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Verilog-2001 variable initialization 

The Verilog-2001 standard adds a convenient short cut for initializ- 
ing variables, following the C language syntax of specifying a vari- 
able’s initial value as part of the variable declaration. Using 
Verilog-2001, the preceding example can be shortened to: 

integer i = 5/ // declare and initialize i 

integer j = i; // declare and initialize j 

Verilog-2001 Verilog-2001 defines the semantics for in-line variable initializa- 
initialization is tion to be exactly the same as if the initial value had been assigned 
nondeterministic i n an initial procedural block. This means that in-line initializa- 
tion will occur in a nondeterministic order, in conjunction with the 
execution of events in other initial procedural blocks and 
always procedural blocks that execute at simulation time zero. 

This nondeterministic behavior can lead to simulation results that 
might not be expected when reading the Verilog code, as in the fol- 
lowing example: 

integer i = 5/ // declare and initialize i 

integer j ; // declare a variable named j 

initial 

j = i; // initialize j to the value of i 

In this example, it would seem intuitive to expect that i would be 
initialized first, and so j would be initialized to a value of 5. The 
nondeterministic event ordering specified in the Verilog-2001 stan- 
dard, however, does not guarantee this. It is within the specification 
of the Verilog standard for j to be assigned the value of i before i 
has been initialized, which would mean j would receive a value of 
X instead of 5. 

SystemVerilog initialization order 

The SystemVerilog standard enhances the semantics for in-line 
variable initialization. SystemVerilog defines that all in-line initial 
values will be evaluated prior to the execution of any events at the 
start of simulation time zero. This guarantees that when initial 
or always procedural blocks read variables with in-line initializa- 
tion, the initialized value will be read. This deterministic behavior 
removes the ambiguity that can arise in the Verilog standard. 



SystemVerilog 
in-line 
initialization is 
before time zero 
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SystemVerilog in-line variable initialization does not cause a 
simulation event. 



Verilog in-line There is an important difference between Verilog semantics and 
initialization may SystemVerilog semantics for in-line variable initialization. Under 
cause an event Verilog semantic rules, in-line variable initialization will be exe- 
cuted during simulation time zero. This means a simulation event 
will occur if the initial value assigned to the variable is different 
than its current value. Note, however, that the current value of the 
variable cannot be known with certainty, because the in-line initial- 
ization occurs in a nondeterministic order with other initial assign- 
ments — in-line or procedural — that are executed at time zero. Thus, 
with Verilog semantics, in-line variable initialization may or may 
not cause simulation events at simulation time zero. 



SystemVerilog SystemVerilog semantics change the behavior of in-line variable 
initialization initialization. With SystemVerilog, in-line variable initialization 
does not cause occurs prior to simulation time zero. Therefore, the initialization 
an event w jn never cause a simulation event within simulation. 



SystemVerilog The simulation results using the enhanced SystemVerilog seman- 
initialization is tics are entirely within the allowed, but nondeterministic, results of 
backward the Verilog initialization semantics. Consider the following exam- 
compatible pi e; 



logic resetN = 0; // declare & initialize reset 

always @(posedge clock, negedge resetN) 

if (! resetN) count <= 0; // active low reset 

else count <= count + 1; 

Verilog in-line Using the Verilog nondeterministic semantics for in-line variable 
initialization is initialization, two different simulation results can occur: 
nondeterministic 

• A simulator could activate the always procedural block first, 
prior to initializing the resetN variable. The always procedural 
block will then be actively watching for the next positive transi- 
tion event on clock or negative transition event on resetN. 
Then, still at simulation time zero, when resetN is initialized to 
0, which results in an X to 0 transition, the activated always pro- 
cedural block will sense the event, and reset the counter at simu- 
lation time zero. 

• Alternatively, under Verilog semantics, a simulator could exe- 
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cute the initialization of resetN before the always procedural 
block is activated. Then, still at simulation time zero, when the 
always procedural block is activated, it will become sensitive to 
the next positive transition event on clock or negative transition 
event on resetN. Since the initialization of resetN has already 
occurred in the event ordering, the counter will not trigger at time 
zero, but instead wait until the next positive edge of clock or 
negative edge of resetN. 

SystemVerilog The in-line initialization rules defined in the Verilog standard per- 
in-line mit either of the two event orders described above. SystemVerilog 
initialization is removes this non-determinism. SystemVerilog ensures that in-line 
deterministic initialization will occur first, meaning only the second scenario can 
occur for the example shown above. This behavior is fully back- 
ward compatible with the Verilog standard, but is deterministic 
instead of nondeterministic. 

2.9.2 Initializing sequential logic asynchronous inputs 

Verilog’s nondeterministic order for variable initialization can 
result in nondeterministic behavior for asynchronous reset or preset 
logic in sequential logic. This nondeterminism can affect resets or 
presets that are applied at the beginning of simulation. 



Example 2-5: Applying reset at simulation time zero with 2-state data types 

module test; 

wire [15:0] count; 
bit clock; 

bit resetN =1; // de-assert reset 

counter dut (clock, resetN, count) ; 

initial begin 

resetN =0; // assert active-low reset 

#5 resetN =1; // de-assert reset 

end 

endmodule 

module counter (input clock, resetN, 

output logic [15:0] count); 

always ©(posedge clock, negedge resetN) 

if (! resetN) count <= 0; // active low reset 

else count <= count + 1; 
endmodule 
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In the example above, the counter has an asynchronous reset input. 
The reset is active low, meaning the counter should reset the 
moment resetN transitions to 0. In order to reset the counter at 
simulation time zero, the resetN input must transition to logic 0. If 
resetN is declared as a 2-state data type such as bit, as in the 
example above, its initial value by default is a logic 0. The model 
changes the initial value to a logic 1, using an in-line initialization 
assignment. 

bit resetN =1; // de-assert reset 

Following Verilog semantic rules, this in-line initialization is exe- 
cuted during simulation time zero, in a nondeterministic order with 
other assignments executed at time zero. In the preceding example, 
two event orders are possible: 

• The in-line initialization could execute first, setting resetN to 1, 
followed by the procedural assignment setting resetN to 0. A 
transition to 0 will occur, and at the end of time step 0, resetN 
will be 0. 

• The procedural assignment could execute first, setting resetN to 
0 (a 2-state data type is already a 0), followed by the in-line ini- 
tialization setting resetN to 1. No transition to 0 will occur, and 
at the end of time step 0, resetN will be 1. 

SystemVerilog removes this non-determinism. With SystemVer- 
ilog, in-line initialization will take place before simulation time 
zero. In the example shown above, resetN will always be initial- 
ized to 1 first, and then the procedural assignment will execute, set- 
ting resetN to 0. A transition from 1 to 0 will occur every time, in 
every software tool. At the end of time step 0, resetN will be 0. 



Initialize variables to their inactive state. 



TIP 

ensuring events The deterministic behavior of SystemVerilog in-line variable ini- 
at time zero tialization makes it possible to guarantee the generation of events at 
simulation time zero. If the variable is initialized using in-line ini- 
tialization to its inactive state, and then set to its active state using 
an initial or always procedural block, SystemVerilog seman- 
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tics ensure that the in-line initialization will occur first, followed by 
the procedural initial assignment. 

In the preceding example, the declaration and initialization of 
resetN would likely be part of a testbench, and the always proce- 
dural block representing a counter would be part of an RTL model. 
Whether in the same module or in separate modules, SystemVer- 
ilog’s deterministic behavior for in-line variable initialization 
ensures that a simulation event will occur at time zero, if a variable 
is initialized to its inactive state using in-line initialization, and then 
changed to its active level at time zero using a procedural assign- 
ment. Verilog’s nondeterministic ordering of in-line initialization 
versus procedural initialization does not guarantee that the desired 
events will occur at simulation time zero. 



2,10 Type casting 



Verilog is Verilog is a loosely typed language that allows a value of one data 
loosely typed type to be assigned to a variable or net of a different data type. 

When the assignment is made, the value is converted to the new 
data type, following rules defined as part of the Verilog standard. 

casting is SystemVerilog adds the ability to cast a value to a different data 
different than type. Type casting is different than converting a value during an 
loosely typed assignment. With type casting, a value can be converted to a new 
type within an expression, without any assignment being made. 

Verilog does not The Verilog 1995 standard did not provide a way to cast a value to 
have type a different data type. Verilog-2001 provides a limited cast capabil- 
casting ity that can convert signed values to unsigned, and unsigned values 
to signed. This conversion is done using the system functions 
$ signed and $unsigned. 



2.10.1 Static (compile time) casting 

SystemVerilog SystemVerilog adds a cast operator to the Verilog language. This 
adds a cast operator can be used to cast a value from one type to another, simi- 
operator lar to the C language. SystemVerilog’s cast operator goes beyond 
C, however, in that a vector can be cast to a different size, and 
signed values can be cast to unsigned or vice versa. 
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To be compatible with the existing Verilog language, the syntax of 
SystemVerilog’s cast operator is different than C’s. 

casting an <type>' (<expression>) — casts a value to any data type, 
expression's including user-defined types. For example: 
data type 

7+ int' (2.0 * 3.0) // cast result of 

// (2.0 * 3.0) to int 

casting an <size>' (<expression>) — casts a value to any vector size. For 
expression's example: 
vector size 

17' (n - 2) // cast operation result 

// to 17 bits wide 

casting an <sign>' (<expression>) — casts a value to signed or unsigned. 
expression's For example: 
signedness 

signed' (y) // cast value to a signed value 

A Verilog concatenation can also be cast. In this case, the parenthe- 
sis around the expression to be cast (the concatenation) can be 
omitted. For example: 

nflag = signed' {a, b} < 0; // cast concatenation 

2.10.2 Dynamic casting 

compile-time The cast operation in SystemVerilog, described above, is a com- 
versus dynamic pile-time cast. The expression to be cast will always be converted 
casting during run time, without any checking that the expression to be cast 
falls within the legal range of the type to which the value is cast. 
When stronger checking is desired, SystemVerilog provides a new 
system function, $cast, that performs dynamic, run-time checking 
on the value to be cast. 

$cast system The $cast system function takes two arguments, a destination 
function variable and a source variable. The syntax is: 

$cast ( dest__var, source__exp ); 

For example: 



int data; 
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always @(posedge clock) 

$cast (data, 3.154 * data ** 2) / 



invalid casts $cast attempts to assign the source expression to the destination 
variable. If the assignment is invalid, a run-time error is reported, 
and the destination variable is left unchanged. Some examples that 
would result in an invalid cast are: 

• Casting a real to an int, when the value of the real number is 
too large to be represented as an int. 

• Casting a value to an enumerated type, when the value does not 
exist in the legal set of values in the enumerated type list. Section 
3.2 on page 52 covers enumerated types in more detail. 



$castcan return $cast is a system function, which returns a status flag indicating 
a status flag whether or not the cast was successful. If the cast is successful, 
$cast returns 1. If the cast fails, the $cast function returns 0, and 
does not change the destination variable. When called as a function, 
no runtime error is reported. 



$cast can be 
called as a task 



$cast can also be called as a task, ignoring the status flag return. 
When called as a task, a runtime error is reported if the cast fails, 
and the destination variable is not changed. 



The primary usage for $cast is to assign expression results to enu- 
merated type variables, which are strongly typed variables. Addi- 
tional examples of using $cast are presented in section 3.2 on 
page 52, on enumerated types. 



2.10.3 Synthesis guidelines 



Use the compile-time cast operator for synthesis. 
TIP 



The static, compile-time cast operator is synthesizable. The 
dynamic $cast system function might not be supported by synthe- 
sis compilers. 

At the time this book was written, the IEEE 1364.1 Verilog RTL 
synthesis standards group had not yet defined the synthesis guide- 
lines for SystemVerilog. As a general rule, however, system tasks 
and system functions are not considered synthesizable constructs. A 
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safe coding style for synthesis is to use the static cast operator for 
casting values. 



2.11 Constants 



Verilog Verilog provides three types of constants: parameter, specparam 
constants and localparam. In brief: 

• parameter is a run-time constant. The value of the constant can 
be redefined during elaboration using defparam or in-line 
parameter redefinition. Only the latter method is synthesizable. 

• specparam is a run-time constant that can be redefined at elabo- 
ration time from SDF files. 

• localparam is an elaboration-time constant that cannot be rede- 
fined. 

These Verilog constants all receive their final value at elaboration 
time. Elaboration is essentially the process of a software tool build- 
ing the hierarchy of the design represented by module instances. 
Some software tools have separate compile and elaboration phases. 
Other tools combine compilation and elaboration into a single pro- 
cess. Because the design hierarchy may not yet be fully resolved 
during elaboration, it is illegal to assign a parameter, specparam 
or localparam constant a value that is derived from elsewhere in 
the design hierarchy. 

constants are Verilog also restricts the declaration of the parameter, spec- 
not allowed in param and localparam constants to modules, static tasks, and 
automatic tasks static functions. It is illegal to declare one of these constants in an 
and functions automatic task or function, or in a begin...end or fork... join 
block. 

the C-iike const SystemVerilog adds the ability to declare any variable as a con- 
declaration stant, using the const keyword. The const form of a constant is 
not assigned its value until after elaboration is complete. This 
means the value assigned to a const form of a constant can use 
values from elsewhere in the design hierarchy. 

The declaration of a const constant must include a data type. Any 
of the Verilog or SystemVerilog variable data types can be speci- 



it is illegal to 
assign 
constants a 
hierarchical 
reference 
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fled as a const constant, including enumerated types and user- 
defined types. 

const bit [23:0] Cl = 7; // 24 -bit constant 

const int C2 = 15; // 32 -bit constant 

const real C3 = 3.14; // real constant 

const C4 = 5; // ERROR, no data type 



const can be 
used in 
automatic tasks 
and functions 



A const constant is essentially a variable that can only be initial- 
ized. Because the const form of a constant receives its value at 
run-time instead of elaboration, a const constant can be declared 
in an automatic task or function, as well as in modules or static 
tasks and functions. Variables declared in a begin.. .end or 
fork... join block can also be declared as a const constant. 



task automatic C; 

const int N = 5; // N is a constant 



endtask 



2,12 Summary 



This chapter introduced and discussed the powerful compilation- 
unit declaration scope. The proper use of compilation-unit scope 
declarations can make it easier to model functionality in a more 
concise manner. A primary usage of compilation-unit scope decla- 
rations is to define new data types using typedef . 

SystemVerilog enhances the ability to specify logic values, making 
it easier to assign values that easily scale to any vector size. 
Enhancements to the 'define text substitution provide new capa- 
bilities to macros within Verilog models and testbenches. 

SystemVerilog also adds a number of new 2-state modeling data 
types to the Verilog language: bit, byte, short int, int, and 
longint. These data types enable modeling designs at a higher 
level of abstraction, using 2-state values. The semantic rules for 2- 
state values are well defined, so that all software tools will interpret 
and execute Verilog models using 2-state logic in the same way. A 
new shortreal data type and a logic data type are also added. 
The initialization of variables is enhanced, so as to reduce ambigu- 
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ities that exist in the Verilog standard. This also helps ensure that 
all types of software tools will interpret SystemVerilog models in 
the same way. SystemVerilog also enhances the ability to declare 
variables that are static or automatic (dynamic) in various levels of 
design hierarchy. These enhancements include the ability to declare 
constants in begin.. .end blocks and in automatic tasks and func- 
tions. 

The next chapter continues the topic on SystemVerilog data types, 
covering user-defined data types and enumerated data types. 




Chapter 3 

SystemVerilog User-Defined 
and Enumerated Data Types 



OystemVerilog makes a significant extension to the Verilog lan- 
O guage by allowing users to define new data types. User-defined 
types allow modeling complex designs at a more abstract level that 
is still accurate and synthesizable. Using SystemVerilog’s user- 
defined types, more design functionality can be modeled in fewer 
lines of code, with the added advantage of making the code more 
self-documenting and easier to read. 

The enhancements presented in this chapter include: 

• Using typedef to create user-defined types 

• Using enum to create enumerated types 

• Working with enumerated values 



3,1 User-defined types 



The Verilog language does not provide a mechanism for the user to 
extend the language data types. While the existing Verilog data 
types are useful for RTL and gate-level modeling, they do not pro- 
vide C-like data types that could be used at higher levels of abstrac- 
tion. SystemVerilog adds a number of new data types for modeling 
at the system and architectural level. In addition, SystemVerilog 
adds the ability for the user to define new data types. 
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typedef defines SystemVerilog user-defined types are created using the typedef 
a user-defined keyword, as in C. User-defined types allow new data type defini- 
data type tions to be created from existing data types. Once a new data type 
has been defined, variables of the new type can be declared. For 
example: 

typedef int unsigned uint; 

uint a, b; // two variables of type uint 

3.1.1 Local typedef declarations 

using typedef User-defined types can be defined either locally or externally, in the 
iocally compilation-unit scope. When a user-defined data type will only be 
used within a specific part of the design, the typedef definition 
can be made within the module or interface representing that por- 
tion of the design. Interfaces are presented in Chapter 9. In the code 
snippet that follows, a user-defined data type called nibble is 
declared, which is used for variable declarations within a module 
called alu. Since the nibble type is defined locally, only the alu 
module can see the definition. Other modules or interfaces that 
make up the overall design are not affected by the local definition, 
and can use the same nibble identifier for other purposes without 
being affected by the local typedef declaration in module alu. 

module alu (...); 

typedef bit [3:0] nibble; 

nibble opA, opB; // variables of the 
// nibble data type 

nibble [7:0] data; // a 32-bit vector made 
// from 8 nibble types 



endmodule 



3.1.2 External typedef declarations 

using typedef When a user-defined data type is to be used in many different mod- 
externaliy els, the typedef declaration can be declared externally, in the 
compilation-unit scope. External declarations are made by placing 
the typedef statement outside of any module, interface or program 
block, as was discussed in section 2.3 on page 11. 
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Example 3-1 illustrates the use of an external typedef declaration 
to create a user-defined data type called dtype_t, that will be used 
throughout the design. The typedef declaration is within an 
'ifdef conditional compilation directive, that defines dtype_t to 
be either the 2-state bit data type or the 4-state logic data type. 
Using conditional compilation, all modules in the compilation unit 
with the external typedef that use the dtype__t user-defined type 
can be quickly modified to model either 2-state or 4-state logic. 

Example 3-1: External typedef declarations 
"ifdef TWO_STATE 

typedef bit dtype_t; // external typedef 

"else 

typedef logic dtype_t; // external typedef 
"endif 

module counter (output dtype_t [15:0] count, 

input dtype_t clock, resetN) ; 

always @(posedge clock, negedge resetN) 
if 

(! resetN) count <= 0; 

else 

count <= count + 1; 

endmodule 



3.1.3 Naming convention for user-defined types 

A user-defined data type can be any legal name in the Verilog lan- 
guage. In large designs, and when using external compilation-unit 
scope declarations, the source code where a new user-defined type 
is defined and the source code where a user-defined type is used 
could be separated by many lines of code, or in separate files. This 
separation of the typedef declaration and the usage of the new 
data types can make it difficult to read and maintain the code for 
large designs. When a name is used in the source code, it might not 
be obvious that the name is actually a user-defined type. 

To make source code easier to read and maintain, a common nam- 
ing convention is to end all user-defined data types with the charac- 
ters “_t”. This naming convention is used in example 3-1, above, 
as well as in many subsequent examples in this book. 
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3,2 Enumerated data types 

Enumerated data types provide a means to declare an abstract vari- 
able that can have a specific list of valid values. Each value is iden- 
tified with a user-defined name. In the following example, variable 
RGB can have the values of red, green and blue: 

enum {red, green, blue} RGB; 

The Verilog language does not have enumerated types. To create 
pseudo names for data values, it is necessary to define a parame- 
ter constant to represent each value, and assign a value to that con- 
stant. Alternatively, Verilog’s 'define text substitution macro can 
be used to define a set of macro names with specific values for each 
name. 

The following example shows a simple state machine sequence 
modeled using parameter constants and 'define macro names: 
The parameters are used to define a set of states for the state 
machine, and the macro names are used to define a set of instruc- 
tion words that are decoded by the state machine. 

Example 3-2: State machine modeled with Verilog ‘define and parameter constants 

"define FETCH 3'hO 
"define WRITE 3' hi 
"define ADD 3'h2 
"define SUB 3'h3 
"define MULT 3'h4 
"define DIV 3'h5 
"define SHIFT 3'h6 
"define NOP 3'h7 

module controller (output reg read, write, 

input wire [3:0] instruction, 

input wire clock, resetN) ; 

parameter WAIT = 0, 

LOAD = 1 , 

STORE - 2; 

reg [1:0] State, NextState; 

always ©(posedge clock, negedge resetN) 
if ( ! resetN) State <= WAIT; 
else State <= NextState; 



Verilog uses 
constants in 
place of enum- 
erated types 
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always @ (State) 
case (State) 

WAIT: NextState = LOAD; 

LOAD: NextState = STORE; 

STORE: NextState = WAIT; 

endcase 

always ©(State, instruction) 

begin 

read = 0; write = 0; 

if (State == LOAD && instruction == v FETCH) 
read = 1; 

else if (State == STORE && instruction == V WRITE) 
write = 1; 

end 

endmodule 



constants do not The variables that use the constant values — State and NextState 
limit the legal set in the preceding example — must be declared as standard Verilog 
of values data types. This means a software tool cannot limit the valid values 
of those signals to just the values of the constants. There is nothing 
that would limit State or NextState in the example above from 
having a value of 3, or a value with one or more bits set to X or Z. 
Therefore, the model itself must add some limit checking on the 
values. At a minimum, a synthesis “full case” pragma would be 
required to specify to synthesis tools that the state variable only 
uses the values of the constants that are listed in the case items. The 
use of synthesis pragmas, however, would not affect simulation, 
which could result in mismatches between simulation behavior and 
the structural design created by synthesis. 

SystemVerilog adds enumerated data type declarations to the Ver- 
ilog language, using the enum keyword, as in C. In its basic form, 
the declaration of an enumerated type is also the same as C. 

enum {WAIT, LOAD, STORE} State, NextState; 

enumerated Enumerated data types can make a model or test program more 
values are readable by providing a way to incorporate meaningful names for 
identified with the values a variable can have. This can make the code more self- 
names documenting and easier to debug. Enumerated data types can be 
referenced or displayed using the enumerated names. 
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Example 3-3 shows the same simple state sequencer as example 3- 
2, but modified to use SystemVerilog enumerated types. 



Example 3-3: State machine modeled with enumerated types 

typedef enum {FETCH, WRITE, ADD, SUB, 

MULT, DIV, SHIFT, NOP } instrj:; 

module controller (output logic read, write, 

input instr__t instruction, 

input wire clock, resetN) / 

enum {WAIT, LOAD, STORE} State, NextState; 

always_ff @(posedge clock, negedge resetN) 
if ( ! resetN) State <= WAIT; 
else State <= NextState; 

always_comb 
case (State) 

WAIT; NextState * LOAD; 

LOAD: NextState = STORE; 

STORE: NextState = WAIT; 

endcase 

always_comb 

begin 

read = 0; write = 0; 

if (State == LOAD && instruction == FETCH) 
read = 1; 

else if (State == STORE && instruction == WRITE) 
write = 1; 

end 

endmodule 



enumerated In this example, the variables State and NextState can only 
types limit the have the valid values of wait, load, and store. All software tools 
legal set of will interpret the legal value limits for these enumerated type vari- 
values a bles in the same way, including simulation, synthesis and formal 
verification. 

The SystemVerilog specialized always_ff and always_comb 
procedural blocks used in the preceding example are discussed in 
more detail in Chapter 5. 
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3.2.1 Enumerated type name sequences 

In addition to specifying a set of unique names, SystemVerilog pro- 
vides two shorthand notations to specify a range of names in an 
enumerated type list. 



Table 3-1 : Specifying a sequence of enumerated list names 



state 


creates a single name of the state 


state [N] 


creates a sequence of names, beginning with stateO, 
statel, ... stateN 


state [N:M] 


creates a sequence of names, beginning with stateN, 
and ending with stateM. If N is less than M, the 
sequence will increment from N to M. If N is greater 
than M, the sequence will decrement from N to M. 



The following example creates an enumerated list with the names 
reset, SO through S5, and W6 through W9: 

enum {RESET, S[5], W [6 : 9] } state; 

3.2.2 Enumerated type name scope 

enumerated The names within an enumerated type list are visible in the scope of 
names must be the enumerated variable declaration. Therefore, each name must be 
unique unique within that scope. The scopes that can contain enumerated 
type declarations are the compilation unit, modules, interfaces, pro- 
grams, begin... end blocks, fork... join blocks, tasks and func- 
tions. 

The following code fragment will result in an error, because the 
enumerated name GO is used twice in the same name scope: 

module FSM (...); 

enum {GO, STOP} fsml_state; 

enum {WAIT, GO, DONE} fsm2_state; // ERROR 



This error in the preceding example can be corrected by placing at 
least one of the enumerated type declarations in a begin... end 
block, which has its own naming scope. 
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module FSM (...); 

always @(posedge clock) 
begin: fsml 

enum {STOP, GO} fsml_state; 

end 

always @(posedge clock) 
begin: fsm2 

enum {WAIT, GO, DONE} fsm2_state; 

end 



3.2.3 Enumerated type values 

enumerated By default, the actual value represented by the name in an enumer- 
type names ated type list is an integer of the int data type. The first name in 
have a default the enumerated list is represented with a value of 0, the second 
value name with a value of 1 , the third with a value of 2, and so on. 

users can SystemVerilog allows the value for each name in the enumerated 
specify the list to be explicitly declared. This allows the abstract enumerated 
name’s value type to be refined, if needed, to represent more detailed hardware 
characteristics. For example, a state machine sequence can be 
explicitly modeled to have one-hot values, one-cold values, 
Johnson-count, Gray-code, or other type of values. 

In the following example, the variable state can have the values 
ONE, five or TEN. Each name in the enumerated list is represented 
as an integer value that corresponds to the name. 

enum {ONE = 1, 

FIVE = 5, 

TEN = 10 } state; 

It is not necessary to specify the value of each name in the enumer- 
ated list. If unspecified, the value representing each name will be 
incremented by 1 from the previous name. In the next example, the 
name A is explicitly given a value of 1, B is automatically given the 
incremented value of 2 and c the incremented value of 3. x is 
explicitly defined to have a value of 24, and Y and z are given the 
incremented values of 25 and 26, respectively. 

enum {A=l, B, C, X=24, Y, Z} listl; 
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name values Each name in the enumerated list must have a unique value. An 
must be unique error will result if two names have the same value. The following 
example will generate an error, because C and D would have the 
same value of 3: 

enum {A=l, B, C, D=3} list2; // ERROR 

3.2.4 Data type of enumerated type values 

enumerated The default data type for enumerated values is int, which is a 32- 
type names bit 2-state data type. In order to represent hardware at a more 
default to int detailed level, SystemVerilog allows an explicit data type for the 
types enumerated values to be declared. For example: 

enum bit [1:0] {WAIT, LOAD, READY} state; 

enum value size If an enumerated name of an explicitly-typed enumerated variable 
is assigned a value, the size must match the size of the data type. 

enum bit [2:0] {WAIT = 3'b001, 

LOAD = 3 ' bOlO , 

READY = 3 'blOO} state; 

It is an error to assign a name a value that is a different size than the 
size declared for the enumerated type. The following example is 
incorrect. The enum variable defaults to an int type. An error will 
result from assigning a 3 -bit value to the names. 

enum {WAIT = 3'b001, // ERROR! 

LOAD = 3'b010, 

READY = 3 ' blOO} state; 

It is also an error to have more names in the enumerated list than 
the value size can represent. 

enum bit {A=l # b0, B, C} list5; 

// ERROR: too many names for 1-bit size 

If the data type of the enumerated values is a 4-state data type, it is 
legal to assign values of X or Z to the enumerated names. 

enum logic {ON=l'bl, OFF=l'bz} out; 

If a value of X or Z is assigned to a name in an enumerated list, the 
next name must also have an explicit value assigned. It is an error to 
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attempt to have an automatically incremented value following a 
name that is assigned an X or Z value. 

enum logic [1:0] 

{WAIT, ERR=2 ' bxx, LOAD, READY} state; 

// ERROR: cannot determine a value for LOAD 

3.2.5 Typed and anonymous enumerations 

Enumerated types can be declared as a user-defined type. This pro- 
vides a convenient way to declare several variables with the same 
enumerated value sets. 

typedef enum {WAIT, LOAD, READY} states__t; 

states_t state, next__state; 

An enumerated type declared as a typedef is commonly referred 
to as a typed enumerated type . If typedef is not used, the enumer- 
ated type is commonly referred to as an anonymous enumerated 
type. 

3.2.6 Strong typing on enumerated type operations 

most data types Most Verilog and SystemVerilog variable data types are loosely 
are loosely typed, meaning that any value of any type can be assigned to a vari- 
typed able. The value will be automatically converted to the data type of 
the variable, following conversion rules specified in the Verilog or 
SystemVerilog standard. 

enumerated Enumerated types are the exception to this general nature of Ver- 
types are ilog. Enumerated types are strongly typed. An enumerated variable 
strongly typed can only be assigned: 

• A named value from its enumerated type list 

• Another enumerated type variable of the same type (that is, 
declared with the same enumerated type list) 

• A value cast to the type of the enumerated variable 

operations use When an operation is performed on an enumerated type value, the 
the data type of enumerated value is automatically converted to the data type and 
the name internal value that represents the name in the enumerated type list. 
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If a data type for the enumerated type names is not explicitly 
declared, the name values will default to int types. 

In the following example: 

typedef enum {WAIT, LOAD, READY} states J: ; 
states_t state, next__state; 
int foo; 

wait will be represented as an int with a value of 0, load as an 
int with a value of 1, and READY as an int value of 2. 

The following assignment operation on the enumerated type is 
legal: 

state = next_state; // legal operation 

The state and next__state are both enumerated type variables of 
the same type. A value in one enumerated type variable can be 
assigned to another enumerated type variable of the same type. 

The assignment statement below is also legal. The enumerated type 
of state is represented as an int, which is added to the literal 
integer 1. The result of the operation is an int value, which is 
assigned to a variable of type int. 

foo = state +1; // legal operation 

The converse of the preceding example is illegal. An error will 
result if a value that is not of the same enumerated type is assigned 
to an enumerated type variable. For example: 

state = foo +1; // ERROR: illegal assignment 

The next examples are also illegal, and will result in errors: 

state = state +1; // illegal operation 

state++; // illegal operation 

next_state += state; // illegal operation 

The enumerated type of state is represented as an int, which is 
added to the literal integer 1. The result of the operation is an int 
value. It is an error to directly assign this int result to a variable of 
the enumerated type states_t. 
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3.2.7 Casting expressions to enumerated types 

casting values The result of an operation can be cast to an enumerated type, and 
to an then assigned to an enumerated type variable of the same type. 
enumerated Either the SystemVerilog cast operator or the dynamic $cast sys- 
tyP e tern function can be used. 

typedef enum {WAIT, LOAD, READY} states_t; 
states_t state, next_state; 

next_state = states_t' (state++) ; // legal 

$cast (next__state, state + 1); // legal 

Note that the Scast function cannot be used with the ++ or += 
operators, as these operations directly modify the target variable. 

using the cast As discussed earlier in section 2.10 on page 43, there is an impor- 
operator tant distinction between using the cast operator and the dynamic 
$cast system function. The cast operator will always perform the 
cast operation and assignment. There is no checking that the value 
to be assigned is in the legal range of the enumerated type set. 
Using the preceding enumerated type example for state and 
next_ state, if state had a value of READY, which is represented 
as a value of 2, incrementing it by one would result in an integer 
value of 3. Assigning this value to next_state is out of the range 
of values within the enumerated type list for next_state. 

This out-of-range value can result in indeterminate behavior. Dif- 
ferent software tools may do different things with the out-of-range 
value. If an out-of-range value is assigned, the actual value that 
might end up stored in the enumerated variable during pre-synthe- 
sis simulation of the RTL model might be different than the func- 
tionality of the gate-level netlist generated by synthesis. 

To avoid ambiguous behavior, it is important that a model be coded 
so that an out-of-range value is never assigned to an enumerated 
type variable. The static cast operator cannot always detect when an 
out-of-range value will be assigned, because the cast operator does 
not do run-time error checking. 

using the $cast The dynamic $cast system function verifies that the expression 
system function result is a legal value before changing the destination variable. In 
the preceding example, if the result of incrementing state is out- 
of-range for next_state, then the call to $cast (next_state, 
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state+l) will not change next_state, and a run-time error will 
be reported. 

The two ways to perform a cast allow the modeler to make an intel- 
ligent trade-off in modeling styles. The dynamic cast is safe 
because of its run-time error checking. However, this run-time 
checking adds some amount of processing overhead to the opera- 
tion, which can affect software tool performance. Also, the $cast 
system function may not be synthesizable. The compile-time cast 
operator does not perform run-time checking, allowing the cast 
operation to be optimized for better run-time performance. 

Users can choose which casting method to use, based on the nature 
of the model. If it is known that out-of-range values will not occur, 
the faster compile-time cast operator can be used. If there is the 
possibility of out-of-range values, then the safer $cast system 
function can be used. Note that the SystemVerilog assert state- 
ment can also be used to catch out-of-range values, but an assertion 
will not prevent the out-of-range assignment from taking place. 
Assertions are discussed in the forthcoming companion book, Sys- 
temVerilog for Verification. 



3.2.8 Special system tasks and methods for enumerated types 



iterating through SystemVerilog provides several functions, referred to as methods , 
the enumerated to iterate through the values in an enumerated type list. These meth- 
type list ods automatically handle the strongly typed nature of enumerated 
types, making it easy to do things such as increment to the next 
value in the enumerated type list, jump to the beginning of the list, 
or jump to the end of the list. Using these methods, it is not neces- 
sary to know the names or values within the enumerated list. 



enumerated 
type methods 
use a C++ 
syntax 



These special methods for working with enumerated lists are called 
in a manner similar to C++ class methods. That is, the name of the 
method is appended to the end of the enumerated variable name, 
with a period as a separator. 



<enum_variable_name>. first — returns the value of the first 
member in the enumerated list of the specified variable. 



<enum__variable__name>. last — returns the value of the last 
member in the enumerated list. 
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<enum_variable_ name > .next (<N>) — returns the value of the 
next member in the enumerated list. Optionally, an integer value 
can be specified as an argument to next. In this case, the Nth next 
value in the enumerated list is returned, starting from the position of 
the current value of the enumerated variable. When the end of the 
enumerated list is reached, a wrap to the start of the list occurs. If 
the current value of the enumerated variable is not a member of the 
enumerated list, the value of the first member in the list is returned. 

<enum_variable_name> .prev (<N>) — returns the value of the 
previous member in the enumerated list. As with the next method, 
an optional integer value can be specified as an argument to prev. 
In this case, the Nth previous value in the enumerated list is 
returned, starting from the position of the current value of the enu- 
merated variable. When the beginning of the enumerated list is 
reached, a wrap to the end of the list occurs. If the current value of 
the enumerated variable is not a member of the enumerated list, the 
value of the last member is returned. 

<enum_var iable jname > . num — returns the number of elements 
in the enumerated list of the given variable. 

<enum_variable_name> .name — returns the string representa- 
tion of the name for the value in the given enumeration variable. If 
the value is not a member of the enumeration, the name method 
returns an empty string. 

Example 3-4 illustrates a state machine model that sequences 
through its states, using some of the enumeration methods listed 
above. The example is a simple 0 to 15 confidence counter , where: 

• The in_sync output is initially 0; it is set when the counter 
reaches 8; in_sync is cleared again if the counter goes to 0. 

• If the compare and synced input flags are both false, the 
counter stays at its current count. 

• If the compare flag and the synced flag are both true, the 
counter increments by 1 (but cannot go beyond 15). 

• If the compare flag is true but the synced flag is false, the 
counter decrements by 2 (but cannot go below 0). 
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Example 3-4: Using special methods to iterate through enumerated type lists 

module conf idence_counter (Input wire synced, compare, 

resetN, clock, 
output logic in_sync) ; 

enum {cnt[0:15]} State, NextState; 

always_ff @(posedge clock, negedge resetN) 
if (IresetN) State <= cntO; 
else State <= NextState; 

always_comb begin 

NextState = State; // default NextState value 
case (State) 

cntO : if (compare && synced) NextState = State. next; 
cntl : begin 

if (compare && synced) NextState = State. next; 
if (compare && ! synced) NextState « State. first ; 

end 

cntl 5 : if (compare && Isynced) NextState = State .prev (2) ; 

default begin 

if (compare && synced) NextState = State. next; 
if (compare && Isynced) NextState = State .prev (2) ; 

end 

endcase 

end 

always__ff @(posedge clock, negedge resetN) 
if (i resetN) in_sync <= 0; 
else begin 

if (State == cnt8) in_sync <= 1; 
if (State == cntO) in__sync <= 0; 

end 

endmodule 



The preceding example uses SystemVerilog’s specialized proce- 
dural blocks, always_ff and always_comb. These procedural 
blocks are discussed in more detail in Chapter 5. 



3.2.9 Printing enumerated types 

printing Enumerated type values can be printed as either the internal value 
enumerated t ^ e namCj or as the name itself. Printing the enumerated variable 

type va ues an jj^tjy w jjj p r j n t the internal value of the enumerated variable. The 
names J r 
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name representing the current value is accessed using the enumer- 
ated type name method. This method returns a string containing the 
name. This string can then be passed to $display for printing. 



Example 3-5: Printing enumerated type variables by value and by name 



enum bit [1:0] {WAIT=2'b01, LOAD=2'blO, READY} State, Next; 

always ©(State) 
begin 

$ displ ay ( "Current state is %s (%b)", State. name, State); 
case (State) 

WAIT: Next = LOAD; 

LOAD: Next = READY; 

READY: Next = WAIT; 
endcase 

$display ( "Next state will be %s (%b)", Next. name, Next); 

end 



3.3 Summary 



The C-like typedef declaration allows users to define new data 
types built up from the predefined data types in Verilog and Sys- 
temVerilog. User-defined types can be used as module ports and 
passed in/out of tasks and functions. 

Enumerated types allow the declaration of variables with a limited 
set of valid values, and the representation of those values with 
abstract names instead of hardware-centric logic values. Enumer- 
ated types allow modeling a more abstract level than Verilog, mak- 
ing it possible to model larger designs with fewer lines of code. 
Hardware implementation details can be added to enumerated type 
declarations, if desired, such as assigning 1-hot encoding values to 
an enumerated type list that represents state machine states. 

SystemVerilog also adds a class data type, enabling an object-ori- 
ented style of modeling. Class objects and object-oriented program- 
ming are primarily intended for verification, and are not currently 
synthesizable. Details and examples of SystemVerilog classes can 
be found in the forthcoming companion book, SystemVerilog for 
Verification . 




Chapter 4 

System Verilog Arrays, 
Structures and Unions 



stem Verilog adds several enhancements to Verilog for repre- 
O senting large amounts of data. The Verilog array constructs are 
extended both in how data can be represented and for operations on 
arrays. Structure and union data types have been added to Verilog 
as a means to represent collections of variables. 



This section presents: 

• Structures 

• Unions 

• Operations on structures and unions 

• Unpacked arrays 

• Packed arrays 

• Operations on arrays 

• Special system functions for working with arrays 

• The $bits “sizeof ’ system function 

• Dynamic arrays, associative arrays and strings 
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4.1 Structures 



Design data often has logical groups of signals, such as all the con- 
trol signals for a bus protocol, or all the signals used within a state 
controller. The Verilog language does not have a convenient mech- 
anism for collecting common signals into a group. Instead, design- 
ers must use ad-hoc grouping methods such as naming conventions 
where each signal in a group starts or ends with a common set of 
characters. 

structures are a SystemVerilog adds C-like structures to Verilog. A structure is a 
collection of collection of variables and/or constants under a single name. The 
variables and/or mem bers (variables or constants) within the structure can be of dif- 
ferent data types, including other structures and arrays. The entire 
collection can be referenced, using the name of the structure. Each 
member within the structure also has a name, which is used to 
select it from the structure. A structure is a convenient way of 
grouping several pieces of related information together. 

A structure differs from an array, in that an array is a collection of 
elements that are all the same type and size, whereas a structure is a 
collection of variables and/or constants that can be different types 
and sizes. Another difference is that the elements of an array are 
referenced by an index into the array, whereas the members of a 
structure are referenced by a member name. 

structures use a A structure is declared using the struct keyword. The structure 
C-like syntax declaration syntax in SystemVerilog is very similar to the C lan- 
guage. The one difference is that C allows for an optional “tag” 
after the struct keyword and before the opening brace. System- 
Verilog does not allow a tag. An example structure declaration is: 

struct { 

int a , b ; 

byte opcode ; 

bit [23:0] address; 

} Instruct ion_Word; 

Structure members can be any variable data type, including user- 
defined types, and any constant type. A structure member is refer- 
enced the same as in C. 



<structure name> . <variable name> 
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For example, to assign a value to the opcode member of the preced- 
ing structure, the reference is: 

Ins truction_Word. opcode = 16'hFOlE; 

Net data types cannot be used within structures. Nets can be 
grouped together under a single name using SystemVerilog inter- 
faces, which are discussed in Chapter 9. 

4.1.1 Typed and anonymous structures 

structures can User-defined data types can be created from structures, using the 
be user-defined typedef keyword, as discussed in section 3.1 on page 49. Declar- 
types j n g a structure as a user-defined type does not allocate any storage. 
Before values can be stored in the members of a structure that is 
defined as a user-defined type, a variable of that user-defined type 
must be declared. 

typedef struct { // structure definition 

int a , b ; 

byte opcode ; 

bit [23:0] address; 

} instruct ion_word__t; 

instruction_word_t IW; // structure allocation 

Local and external structure definitions 

A structure type can be defined within a module or interface, allow- 
ing its use throughout that model. A structure can also be defined 
externally, in the compilation-unit scope, so that it can be used in 
any number of modules or interfaces. Section 2.3 on page 1 1, dis- 
cusses SystemVerilog’s compilation-unit scope. 

Anonymous structures 

When a structure is declared without using typedef, it is referred 
to as an anonymous structure. 

struct { 

int a , b ; 

byte opcode ; 

bit [23:0] address; 

} instruction; 
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4.1.2 Assigning values to structures 
Initializing structures 

structures can The members of a structure can be initialized at the time the struc- 

be initialized ture is instantiated, using a set of values enclosed in { } braces. 

using a C-like num ber of values must exactly match the number of members. 
syntax 

typedef struct { 
int a , b ; 

byte opcode ; 

bit [23:0] address; 

} instruct ion__word_t ; 

instruction_word_t IW = {100, 3, 8'hFF, 0}; 

A similar syntax is used for defining structure constants or structure 
parameters. 

Assigning to structure members 

three ways to A value can be assigned to any member of a structure by referenc- 
assign to ing the name of the member. 
structures 

typedef struct { 
int a, b ; 

byte opcode ; 

bit [23:0] address; 

} instr_t; 

instr__t IW; 

always @(posedge clock, negedge resetN) 
if (! resetN) begin 
IW.a = 100; 

IW.b = 5; 

IW. opcode = 8'hFF; 

IW. address = 0; 

end 

else begin 



end 
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Assigning structure expressions to structures 

a structure A complete structure can be assigned a structure expression. A 
expression is structure expression is formed using a comma-separated list of val- 
enclosedm^O ues enc j ose d in { } braces, just as when initializing a structure. The 
braces must contain a value for each member of the structure. 

always @(posedge clock, negedge resetN) 
if (! resetN) IW = {100, 5, 8'hFF, 0}; 
else begin 

end 

The values in the structure expression can be listed in the order in 
which they are defined in the structure. Alternatively, the structure 
expression can specify the names of the structure members to 
which values are being assigned, where the member name and the 
value are separated by a colon. When member names are specified, 
the expression list can be in any order. 

IW = {address :0, opcode : 8 ' hFF, a: 100, b:5}; 

It is illegal to mix listing by name and listing by order in the same 
structure expression. 

IW = {address :0, 8 ' hFF, 100, 5}; // ERROR 



a structure 
expression can 
be listed by 
order or by 
member name 



Default values in structure expressions 



some or all 
members of a 
structure can be 
assigned a 
default value 



A structure expression can specify a value for multiple members of 
a structure by specifying a default value. The default value can be 
specified for all members of a structure, using the default key- 
word. 



IW = {default : 0 } ; // set all members of IR to 0 



The default value can also be specified just for members of a spe- 
cific data type within the structure, using the keyword for the data 
type. The default keyword or data type keyword is separated 
from the value by a colon. 



typedef struct { 
real x, y; 

lnt a , b ; 

byte opcode ; 
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bit [23:0] address; 

} instruction_word_t; 

instruction__word_t IW; 

always @(posedge clock, negedge resetN) 
if (! resetN) 

IW = { real : 1 . 0 , default:0 }; 

// assign all real members a default of 1.0 
// and all other members a default of 0 

else begin 

end 

The default value assigned to structure members must be compati- 
ble with the data type of the member. Compatible values are ones 
that can be cast to the member’s data type. 

default value There is a precedence in how structure members are assigned val- 
precedence ue s. The default keyword has the lowest precedence, and will be 
overridden by any data type-specific defaults. Data type-specific 
default values will be overridden by any explicitly named member 
values. The following structure expression will assign ri a value of 
1.0, r2 a value of 3.1415, and all other members of the structure a 
value of 0. 

typedef struct { 
real rO , rl ; 
int i0, il; 
bit [15:0] opcode; 

} instruct ion_word_t; 

instruction_word_t IW; 

IW = { real : 1 . 0 , default-.O, rl:3.1415 }; 

4.1.3 Packed and unpacked structures 

unpacked By default, a structure is unpacked . This means the members of the 
structures can structure are treated as independent variables that are grouped 
have padding together under a common name. SystemVerilog does not specify 
how software tools should store the members of an unpacked struc- 
ture. The layout of the storage can vary from one software tool to 
another. 
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packed 
structures are 
stored without 
padding 



A structure can be explicitly declared as a packed structure, using 
the packed keyword, A packed structure stores all members of the 
structure as contiguous bits, in a specified order. A packed structure 
is stored as a vector, with the first member of the structure being the 
left-most field of the vector. The right-most bit of the last member 
in the structure is the least-significant bit of the vector, and is num- 
bered as bit 0. This is illustrated in figure 4-1. 



struct packed { 

bit valid; 
byte tag; 
bit [31:0] data; 
} data_word; 



Figure 4-1 : Packed structures are stored as a vector 
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The members of a packed structure can be referenced by either the 
name of the member or by using a part select of the vector repre- 
sented by the structure. The following two assignments will both 
assign to the tag member of the data_word structure: 

data_word. tag = 8'hfO; 

data_word [39 : 32] = 8'hfO; // same bits as tag 

Packed structures can only contain integral values. 

packed All members of a packed structure must be integral values. An inte- 
structures must gral value is a value that can be represented as a vector, such as 
contair^packw^ byte, int and vectors created using bit or logic types. A struc- 
ture cannot be packed if any of the members of the structure cannot 
be represented as a vector. This means a packed structure cannot 
contain real or shortreal variables, unpacked structures, 
unpacked unions, or unpacked arrays. 
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Operations on packed structures 

packed Because a packed structure is stored as a vector, operations on the 
structures are complete structure are treated as vector operations. Therefore, math 
seen as vectors 0 p era ti 0 ns, logical operations, and any other operation that can be 
performed on vectors can also be performed on packed structures. 



typedef struct packed { 
bit valid; 
byte tag; 
bit [31:0] data; 

} data_word__t ; 

data_word__t packet_in, packet_out; 

always @(posedge clock) 

packet__out <= packet_in << 2; 

Note that when a packed structure is assigned a list of values in { } 
braces, as discussed in section 4.1.2 on page 68, values in the list 
are assigned to members of the structure. The packed structure is 
treated the same as an unpacked structure in this circumstance, 
rather than as a vector. The values within the { } braces are sepa- 
rate values for each structure member, and not a concatenation of 
values. 

packet__in = {l, '1, 1024}; 

The preceding line assigns 1 to valid, FF to tag, and 1024 to 
data. 

Signed packed structures 

a packed Packed structures can be declared with the signed or unsigned 
structures used keywords. These modifiers affect how the entire structure is per- 
as ce i ye d when used as a vector in mathematical or relational opera- 

unsigned ^ ons * They not a ^ ect how members of the structure are 
perceived. Each member of the structure is considered signed or 
unsigned, based on the data type declaration of that member. A 
part-select of a packed structure is always unsigned, the same as 
part selects of vectors in Verilog. 

typedef struct packed signed { 

bit valid; 
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byte tag; 

bit signed [31:0] data; 

} data_word_t ; 

data_word_t A, B; 

always @(posedge clock) 

if ( A < B ) // signed comparison 



4.1.4 Passing structures through ports 

ports can be Structures can be passed through module ports. The structure must 
declared as a first be defined as a user-defined data type using typedef , which 
structure type then a u ows the module or interface port to be declared as the struc- 
ture type. Software tools must read in the typedef definition of the 
structure before reading in the declaration of the module or inter- 
face that references the structure type. 

typedef struct { //typedef is external to module 
int a , b ; 

byte opcode ; 

bit [23:0] address; 

} instruction_word_t ; 

module alu (input instruction_word_t IW, 

input wire clock) ; 



endmodule 

When an unpacked structure is passed through a module port, a 
structure of the exact same type must be connected on each side of 
the port. Anonymous structures declared in two different modules, 
even if they have the exact same name, members and member 
names, are not the same type of structure. Passing unpacked struc- 
tures through module ports is discussed in more detail in section 
8.6.2 on page 211. 

4.1.5 Passing structures as arguments to tasks and functions 

structures can Structures can be passed as arguments to a task or function. To do 

be passed to so, the structure must be defined as a user-defined data type using 

tasks and type< i e f so that the task or function argument can then be 
functions , , . . 

declared as the structure type. 
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module processor (...); 

typed© f struct { // typedef is local 

int a , b ; 

byte opcode ; 

bit [23:0] address; 

} instruct ion_word_t ; 

function alu (input instruct ion_word_t IW) ; 

end function 
endmodule 

When a task or function is called that has an unpacked structure as a 
formal argument, a structure of the exact same type must be passed 
to the task or function. An anonymous structure, even if it has the 
exact same members and member names, is not the same type of 
structure. 

4.1.6 Synthesis guidelines 

Both unpacked and packed structures are synthesizable. Synthesis 
supports passing structures through module ports, and in/out of 
tasks and function. Assigning values to structures by member name 
and as a list of values is supported. 



4.2 Unions 



a union only SystemVerilog adds C-like unions to Verilog. A union is a single 
stores a single storage element that can have multiple representations. Each repre- 
va/ue sen tation of the storage can be a different data type. 

The declaration syntax for a union is similar to a structure, and 
members of a union are referenced in the same way as structures. 

union { 
int i ; 

int unsigned u; 

} data; 

data.i = -5; 

$display ("data is %d" , data.i); 
data.u = -5; 

$display ( "now data is %d", data.u); 




Chapter 4: SystemVerilog Arrays, Structures and Unions 



75 



unions reduce Although the declaration syntax is similar, a union is very different 
storage and than a structure. A structure can store several values. It is a collec- 
may improve t j on 0 f var i a bl es under a single name. A union can only store one 
p value. A typical application of unions is when a value might be rep- 

resented as several different data types, but only as one type at any 
specific moment in time. 

4.2.1 Typed and anonymous unions 

A union can be defined as a data type using typedef , in the same 
way as structures. A union that is defined as a user-defined type is 
referred to as a typed union. If no typedef is used, the union is 
referred to as an anonymous union. 

typede£ union { 
int i ; 

int unsigned u; 

} data_t ; 

data_t a, b; // two variables of type data_t 

4.2.2 Unpacked unions 

An unpacked union can contain any variable data type, including 
real types and unpacked structures. Software tools can store val- 
ues in unpacked unions in an arbitrary manner. There is no require- 
ment that each tool align the storage of the different data types used 
within the union in the same way. 




Reading from an unpacked union member that is different than 
the last member written may cause indeterminate results. 



If a value is written to and read from the same unpacked union 
member type, then the value is unchanged. If, however, a value is 
stored in the unpacked union using one member type, and read back 
using a different member type, then the value read will be con- 
verted according to the mapping of the data types. This mapping is 
defined for packed unions (described in section 4.2.3), but is not 
defined for unpacked unions, and so may yield different results in 
different software tools. 
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The following example shows a union that can store a value as 
either an int data type or a real data type. Since these data types 
are stored very differently, it is important that a value always be 
read back from the union in the same data type with which it is 
written. Therefore, the example contains extra logic to track how 
values were stored in the union. The union is a member of a struc- 
ture. A second member of the structure is a flag that can be set to 
indicate that a real value has been stored in the union. When a value 
is read from the union, the flag can be checked to determine what 
data type the union is storing. 

struct { 

bit is_real; 
union { 
int i ; 
real r; 

} value; 

} data ; 

//... 

always @(posedge write) begin 
case (operation_type) 

INT_OP: begin 

data.value.i <= 5; 
data. is_real <= 0; 
end 

FP_OP : begin 

data. value. r <= 3.1415; 
data. is_real <= 1; 

end 

endcase 

end 

//... 

always ©(posedge read) begin 
if (data. is_real) 

real_operand <= data. value . r; 

else 

int_operand <= data.value.i; 

end 



4.2.3 Packed unions 

packed union A union can be declared as packed in the same way as a structure. 
members all in a packed union, the number of bits of each union member must 
have the same t ^ e same This ensures that a packed union will represent its stor- 
age with the same number of bits, regardless of member in which a 
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value is stored. If any member of a packed union is a 4-state type, 
then the union is 4-state. 

A packed union cannot contain real or shortreal variables, 
unpacked structures, unpacked unions, or unpacked arrays. 

A packed union allows data to be written using one format and read 
back using a different format. The design model does not need to do 
any special processing to keep track of how data was stored. This is 
because the data in a packed union will always be stored using the 
same number of bits and bit alignment. 

The following example defines a packed union in which a value can 
be represented in two ways: either as a data packet (using a packed 
structure) or as an array of bytes. 

typedef struct packed { 

bit [15:0] source_address; 
bit [15:0] destination_address ; 
bit [23:0] data; 
bit [ 7:0] opcode; 

} data__packet_t ; 

union packed { 

data_packet__t packet; // packed structure 
bit [7:0] [7:0] bytes; // packed array 
} dreg; 

Figure 4-2: Packed union with two representations of the same storage 
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Because the union is packed, the information will be stored using 
the same bit alignment, regardless of which union representation is 
used. This means a value could be loaded using the array of bytes 
format (perhaps from a serial input stream of bytes), and then the 
same value can be read using the data_packet format. 




78 



SystemVerilog for Design 



always @(posedge clock, negedge resetN) 
if (! resetN) begin 

dreg. packet <= '0; // store as packet type 

i <= 0 ; 

end 

else if (load_data) begin 

dreg. bytes [i] <= byte_in; // store as bytes 
i <= i + 1; 

end 

always @(posedge clock) 
if ( da t already) 

case (dreg. packet .opcode) // read as packet 



4.2.4 Synthesis guidelines 




Only packed unions are synthesizable. 



packed unions A union only stores a single value, regardless of how many data 
can be type representations are in the union. To realize the storage of a 
synthesized un j on j n hardware, all members of the union must be stored as the 
same vector size using the same bit alignment. Packed unions rep- 
resent the storage of a union in this way, and are synthesizable. An 
unpacked union does not guarantee that each data type will be 
stored in the same way, and is therefore not synthesizable. 



4.2.5 An example of using structures and unions 

Structures provide a mechanism to group related data together 
under a common name. Each piece of data can be referenced indi- 
vidually by name, or the entire group can be referenced as a whole. 
Unions allow one piece of storage to be used in multiple ways. 

The following example models a simple Arithmetic Logic Unit that 
can operate on either signed or unsigned values. The ALU opcode, 
the two operands, and a flag to indicate if the operation data is 
signed or unsigned, are passed into the ALU as a single instruction 
word, represented as a structure. The ALU can operate on either 
signed values or unsigned values, but not both at the same time. 
Therefore the signed and unsigned values are modeled as a union of 
two data types. This allows one variable to represent both signed 
and unsigned values. 
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Chapter 10 presents another example of using structures and unions 
to represent complex information in a simple and intuitive form. 

Example 4-1: Using structures and unions 

typedef enum {ADD, SUB, MULT, DIV, SL, SR} opcode_t; 

typedef enum {UNSIGNED, SIGNED} operand_type_t ; 

typedef union packed { 
logic [31:0] u_data; 

bit signed [31:0] s_data; 

} data_t; 

typedef struct packed { 

opcode_t opc ; 

operand_type_t op_type ; 
data_t op_a; 

data_t op_b; 

} instr_t; 

module alu (input instr_t IW, output data__t alu_out) / 

always @(IW) begin 

if (IW.op_type == SIGNED) begin 
case (IW.opc) 

ADD : alu_out . s_data = IW.op__a. s_data + IW.op_b. s__data; 

SUB : alu_out . s__data * IW.op_a. s_data - IW. op_b. s_data; 

MULT: alu_out . s_data = IW.op__a. s_data * IW.op__b. s_data; 
DIV : alu_out . s_data = IW . op_a . s__data / IW.op__b. s__data; 
SL : alu__out . s_data = IW.op__a. s_data <<< 2; 

SR : alu_out . s_data = IW . op_a . s__data >>> 2; 

endcase 
end 

else begin 
case (IW.opc) 

ADD : alu_out .u_data = IW.op_a.u__data + IW.op__b.u_data; 

SUB : alu__out .u_data = IW.op_a.u_data - IW.op_b.u_data; 

MULT: alu_out .u_data = IW.op_a.u_data * IW.op__b.u_data; 
DIV : alu_out .u_data = IW.op_a.u_data / IW.op_b.u_data; 
SL : alu__out .u_data = IW . op_a . u__data << 2; 

SR : alu_out ,u_data = IW.op_a.u_data >> 2; 

endcase 
end 
end 

endmodule 
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4,3 Arrays 

4.3.1 Unpacked arrays 

Verilog‘1995 The basic syntax of a Verilog array declaration is: 
arrays 

<data_type> <vector__size> <array_name> <array_dimensions> 
For example: 

reg [15:0] RAM [0:4095]; // memory array 

Verilog- 1995 only permitted one-dimensional arrays. A one- 
dimensional array is often referred to as a memory, since its pri- 
mary purpose is to model hardware memory devices such as RAMs 
and ROMs. Verilog- 1995 also limited array declarations to just the 
data types reg, Integer and time. 

Verilog-2001 Verilog-2001 significantly enhances Verilog- 1995 arrays by allow- 
arrays ing any data type except the event type to be declared as an array, 
and by allowing multi-dimensional arrays. With Verilog-2001, both 
variable types and net types can be used in arrays. 

//a 1-dimensional unpacked array of 
// 1024 1-bit nets 
wire n [0:1023] ; 

//a 1-dimensional unpacked array of 
// 256 8 -bit variables 
reg [7:0] LOT [0:255]; 

// a 1 -dimensional unpacked array of 
// 1024 real variables 
real r [0:1023] ; 

//a 3 -dimensional unpacked array of 
// 32-bit int variables 
integer i [7 : 0] [3 : 0] [7:0] ; 

Verilog restricts Verilog restricts the access to arrays to just one element of the array 
array access to at a time, or a bit-select or part-select of a single element. Any 
one element afa attempt to either read or write to multiple elements of an array is an 
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integer i £7:0] [3:0] [7:0] ; 
integer j ; 

j = i[3] [0] [1] ; // legal: selects 1 element 
j = i[3] [0] ; // illegal: selects 8 elements 



unpacked arrays 
store each 
element 
independently 



SystemVerilog refers to the Verilog style of array declarations as 
unpacked arrays. With unpacked arrays, each element of the array 
is stored independent from other elements, but grouped under a 
common array name. Verilog does not define how software tools 
should store the elements in the array. For example, given an array 
of 8-bit wide elements, a simulator or other software tool might 
store each 8-bit element in 32-bit words. Figure 4-3 illustrates how 
the following declaration might be stored within memory. 



wire [7:0] table [3:0]; 



Figure 4-3: Unpacked arrays can store each element independently 
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SystemVerilog enhancements to unpacked arrays 

SystemVerilog SystemVerilog extends unpacked array dimensions to include the 
allows unpacked Verilog event data type, and all the SystemVerilog data types. 
arra datat ny e These are logic, bit, byte, int, longint, shortreal, and 
real. Unpacked arrays of user-defined types defined using type- 
def can also be declared, including types using struct and enum. 

bit [63:0] d_array [1:128]; // array of vectors 

shortreal cosines [0:90]; // array of floats 

typedef enum {Mo, Tu, We, Th, Fr, Sa, Su} Week; 
Week Year [1:52]; // array of Week types 
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SystemVehlog SystemVerilog also adds to Verilog the ability to reference an 
can reference all entire unpacked array or a slice of multiple elements within an 
or slices of an unpaid array. A slice is one or more contiguously numbered ele- 
arra Y ments w jthin one dimension of an array. These enhancements make 
it possible to copy the contents of an entire array, or a specific 
dimension of an array into another array. 




The left-hand and right-hand sides of an unpacked array copy 
must have identical layouts. 



copying into In order to directly copy multiple elements into an unpacked array, 
multiple the layout of the array or array slice on the left-hand side of the 
elements of an ass ig nmen t must exactly match the layout of the right-hand side. 
H 7 That is, the element size and the number of dimensions copied must 

be the same. 



The following examples are legal. Even though the array dimen- 
sions are not numbered the same, the size and layout of each is the 
same. 

int al [7:0] [1023:0]; // unpacked array 

byte a2 [1:8] [1:1024]; // unpacked array 

a2 = al; // copy an entire array 

a2 [3] = al[0] ; // copy a slice of an array 

An unpacked array can be copied to an array of a different size 
using bit-stream casting. This is presented later in this chapter, in 
section 4.3.7 on page 91. 



Simplified unpacked array declarations 

C arrays are C language arrays always begin with address 0. Therefore, an array 
specified by size declaration in C only requires that the size of the array be specified. 
For example: 

int array [20] ; // a C array with addresses 

// from 0 to 19 



Verilog arrays Hardware addressing does not always begin with address 0. There- 
are specified by fore, Verilog requires that array declarations specify a starting 
address range ac jd ress anc j an ending address of an array dimension. 
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int array [64:83]; // a Verilog array with 

// addresses from 64 to 83 

SystemVerilog SystemVerilog adds C-like array declarations to Verilog, allowing 

unpacked arrays unpacked arrays to be specified with a dimension size, instead of 

can also be s t ar ting and ending addresses. The array declaration: 
specified by size 

logic [31:0] data [1024]; 

is equivalent to the declaration: 

logic [31:0] data [0:1023]; 

As in C, the unpacked array elements are numbered, starting with 
address 0 and ending with address size-l. 

The simplified C-style array declarations cannot be used with 
packed arrays. The following example is a syntax error. 

bit [32] d; // illegal packed array declaration 

4.3.2 Packed arrays 

The Verilog language allows vectors to be created out of single-bit 
data types, such as reg and wire. The vector range comes before 
the signal name, whereas an unpacked array range comes after the 
signal name. 

Verilog vectors SystemVerilog refers to vector declarations as packed arrays. A 

are one - Verilog vector is a one-dimensional packed array. 
dimensional 

packed arrays wire [3;0 ] select; // 4-bit vector 
reg [63:0] data; // 64 -bit vector 

SystemVerilog SystemVerilog adds the ability to declare multiple dimensions in a 
allows multi- packed array. 
dimensional 
packed arrays 

bit [3:0] [7:0] data; // 2-D packed array 

packed arrays SystemVerilog defines how the elements of a packed array are 
have no padding stored. The entire array must be stored as contiguous bits, which is 
the same as a vector. Each dimension of a packed array is a sub 
field within the vector. 
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In the packed array declaration above, there is an array of 4 8-bit 
sub-arrays. Figure 4-4 illustrates how the two-dimensional array 
above will be stored, regardless of the software compiler, operating 
system or platform. 

Figure 4-4: Packed arrays are stored as contiguous elements 



bit [3:0] [7:0] data; // 2-D packed array 



31 


23 


15 


7 0 


data[3][7:0] 


data[2][7:0] 


data[1][7:0] 


data[0][7:0] 



Packed array data types 

Only bit-wise data types can be packed. 

Packed arrays can only be formed from bit-wise data types, which 
are logic, bit, reg, wire, wand, tri, triand, trior, trio, 
tril, trireg, other packed arrays, packed structures, and packed 
unions. 

wire [1:0] [3:0] [3:0] bus; // 3-D packed array 




typedef struct packed { 
byte crc; 
int data; 

} data_word; 

data_word [7:0] darray; 



// 1-D packed array of 
// packed structures 



Referencing packed arrays 

A packed array can be referenced as a whole, as bit-selects, or as 
part-selects. Multidimensional packed arrays can also be referenced 
in slices. A slice is one or more contiguous dimensions of an array. 
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bit [3:0] [7:0] data; // 2-D packed array 



wire [31:0] out = data; 
wire sign = data [3] [7] ; 
wire [3:0] nib = data [0] [3:0]; 
byte high_byte = data [3] ; 
logic [15:0] word = data [1:0]; 



// whole array 
// bit-select 
// part-select 
// 8-bit slice 
// 2 slices 



Operations on packed arrays 

any vector Because packed arrays are stored as vectors, any legal operation 
operation can that can be performed on a Verilog vector can also be performed on 

be performed on p ac k ec j arrays. This includes being able to do bit-selects and part- 
packed arrays , r , 

7 selects from the packed array, concatenation operations, math oper- 
ations, relational operations, bit-wise operations, and logical opera- 
tions. 

bit [3:0] [15:0] a, b, result; // packed arrays 
result = (a << 1) + b; 

packed arrays There is no semantic difference between a Verilog vector and a 
use Verilog SystemVerilog packed array. Packed arrays use the standard Ver- 
vector rules jj Q g vector rules for operations and assignment statements. When 
there is a mismatch in vector sizes, a packed array will be truncated 
on the left or extended to the left, just as with a Verilog vector. 



4.3.3 Using packed and unpacked arrays 

The ability to declare multi-dimensional arrays as either packed 
arrays or unpacked arrays gives a great deal of flexibility on how to 
represent large amounts of complex data. Some general guidelines 
on when to use each type of array follow. 

Use unpacked arrays to model: 

• Arrays of byte, int. Integer, real, unpacked structures, 
unpacked unions, and other data types that are not bit-wise types 

• Arrays where typically one element at a time is accessed, such as 
with RAMs and ROMs 



use unpacked 
arrays to model 
memories, and 
with abstract 
data types 
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module ROM (...); 
byte mem [0:4095] ; 

assign data = select? mem [address] : 'z; 



use packed Use packed arrays to model: 
arrays to create 

vectors with • Vectors made up of 1-bit data types (the same as in Verilog) 
sub-fields 

• Vectors where it is useful to access sub-fields of the vector 
bit [39:0] [15:0] packet; // 40 16-bit words 

packet = input_stream; // assign to all words 

data = packet [24]; // select 1 16-bit word 

tag = packet [3] [7:0]; // select part of 1 word 



4.3.4 Initializing arrays at declaration 



Packed array initialization 



packed arrays Packed arrays can be initialized at declaration using a simple 

are initialized assignment, like vectors in Verilog. The assignment can be a con- 

the same as stant va i ue a concatenation of constant values or a replication of 
with vectors . A r 

constant values. 



logic [3 : 0] [7 : 0] a = 32 ' h0; // vector assignment 

logic [3:0] [7:0] b = { 16 ' hz , 16 ' ho } ; // concatenate operator 

logic [3:0] [7:0] c ■ { 16 { 2 ' boi } } ; // replicate operator 



Unpacked array initialization 

unpacked arrays Unpacked arrays can be initialized at declaration, using a list of val- 
are initialized ue s enclosed in { } braces for each array dimension. This syntax is 
Values s * m ^ ar t0 ass ig n i n S a ^ st °f values to an array in C. Note, however, 
that the C shortcut of omitting the inner braces is not allowed in 
SystemVerilog. The assignment requires nested sets of braces that 
exactly match the dimensions of the array. 
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int dl [0:1] [0:3] = { {7, 3, 0,5}, {2, 0,1, 6} } ; 
// dl [0] [0] = 7 
// dl [0] [1] = 3 
// dl [0] [2] = 0 
// dl [0] [3] = 5 

// dl[l] [0] = 2 
// dl[l] [1] = 0 
// dl[l] [2] . 1 
// dl[l] [3] = 6 



SystemVerilog provides a shortcut for declaring a list of values. An 
inner list for one dimension of an array can be repeated any number 
of times using a Verilog-like replicate factor. 



int d2 [0:1] [0:3] = { 2{{7,3,0,5}} } ; 
// d2 [0] [0] = 7 
// d2 [0] [1] = 3 
// d2[0] [2] = 0 
// d2 [0] [3] = 5 

// d2 [1] [0] = 7 
// d2[l] [1] = 3 
// d2 [1] [2] = 0 
// d2 [1] [3] = 5 




The { } list operator is not the same as the Verilog { } 
concatenate operator and {{ }} replicate operator. 



the { } braces When initializing an unpacked array, the { } braces represent a list 
are used two of values. This is not the same as a Verilog concatenate operation. 
ways a s a ij st 0 f values, each value is assigned to its corresponding ele- 
ment, following the same rules as Verilog assignment statements. 
This means unsized literal values can be specified in the list, as well 
as real values. 

The Verilog concatenation and replication operators also use the 
{ } braces, but these operators require that literal values have a size 
specified, in order to create the resultant single vector. Unsized 
numbers and real values are not allowed in concatenation and repli- 
cation operators. 
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Specifying a default value for unpacked arrays 

an array can be SystemVerilog provides a mechanism to initialize all the elements 
initialized to a 0 f an unpacked array, or a slice of an unpacked array, by specifying 
default value a d e f au it value. The default value is specified within { } braces 
using the default keyword, which is separated from the value by 
a colon. The value assigned to the array must be compatible with 
the data type of the array. A value is compatible if it can be cast to 
that data type. 

int al [0:7] [0:1023] = {default : 8 ' h55 } ; 

An unpacked array can also be an array of structures or other user- 
defined types (see section 4.3.1 1 on page 94). These constructs can 
contain multiple data types. To allow initializing different data 
types within an array to different values, the default value can also 
be specified using the keyword for the data type instead of the 
default keyword. A default assignment to the array will automat- 
ically descend into structures or unions to find variables of the 
specified data type. Refer to section 4.1.2 on page 68, for an exam- 
ple of specifying default values based on data types. 

4.3.5 Assigning values to arrays 

Assigning values to unpacked arrays 

The Verilog language supports two ways to assign values to 
unpacked arrays: 

• A single element can be assigned a value. 

• A bit-select or part select of a single element can be assigned a 
value (added as part of the Verilog-2001 standard). 

SystemVerilog extends Verilog with two additional ways to assign 
values to unpacked arrays: 

• The entire array can be assigned a list of values. 

• A slice of the array can be assigned a list of values. 



The list of values is specified between { } braces, the same as with 
initializing unpacked arrays, as discussed in section 4.3.4 on page 
86 . 
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byte a [0:3] [0:3] ; 

a[l] [0] = 8'h5; // assign to one element 

a = {{0,1,2, 3}, {4,5, 6,7}, {7, 6, 5,4}, {3, 2, 1,0}}; 
// assign a list of values to the full array 

a [3] = {'hF, ' hA, 'hC, 'hE}; 

// assign list of values to slice of the array 

The list of assignments to an unpacked array can also specify a 
default assignment, using the default keyword. As procedural 
assignments, specific portions of an array can be set to different 
default values. 

always @(posedge clock, negedge resetN) 
if (! resetN) begin 

a = {default: 0}; // init entire array 

a[0] = {defaults}; // init slice of array 

end 

else begin 
//... 
end 



Assigning values to packed arrays 

multi - Packed arrays are vectors (that might happen to have sub-fields), 
dimensional and can be assigned values, just as with Verilog vectors. A packed 
packed arrays arra y can ass ig ne( j a value: 
are vectors with 

sub-fields „ , , 

• To one element of the array 

• To the entire array (vector) 

• To a part select of the array 

• To a slice (multiple contiguous sub-fields) of the array 



bit [1:0] [1:0] [7:0] a; // 3-D packed array 

a[l] [1] [0] = 1'bO; // assign to one bit 

a = 32 ' hFlA3C5E7 ; // assign to full array 

a[l] [0] [3:0] = 4'hF; // assign to a part select 
a[0] = 16'hFACE; // assign to a slice 
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4,3.6 Copying arrays 



Assigning packed arrays to packed arrays 

assigning A packed array can be assigned to another packed array. Since 
packed array to packed arrays are treated as vectors, the arrays can be of different 
packed array us s j zes standard Verilog assignment rules for vectors are used to 
u truncate or extend the arrays if there is a mismatch in array sizes. 

bit [1:0] [15:0] a; // 32 bit vector 

bit [3:0] [ 7:0] b; // 32 bit vector 

logic [15:0] c; // 16 bit vector 

logic [39:0] d; // 40 bit vector 

b = a; // assign 32-bit array to 32-bit array 

c = a; // upper 16 bits will be truncated 

d = a; // upper 8 bits will be zero filled 

Assigning unpacked arrays to unpacked arrays 

assigning Unpacked arrays can be directly assigned to unpacked arrays only 
unpacked array if both arrays have exactly the same number of dimensions and ele- 

arra° te 'aNowed ment s * zes ’ assignment is done by copying each element of one 
array is a owe arra y t0 corresponding element in the destination array. The 

array elements in the two arrays do not need to be numbered the 
same. It is the layout of the arrays that must match exactly. 

int a [2:0] [9:0], b [1 : 3] [1 : 10] ; 

a = b; // assign unpacked array to unpacked 
// array 

assigning If the two unpacked arrays are not identical in layout, the assign- 

unpacked arrays ment can still be made using a bit-stream cast operation. Bit-stream 

of different sizes cas ti n g is presented later in this chapter, in section 4.3.7 on page 9 1 . 
requires casting r r r & 



Assigning unpacked arrays to packed arrays 

assigning An unpacked array cannot be directly assigned to a packed array. 
unpacked arrays This is because in the unpacked array, each element is stored inde- 
to packed arrays p enc j en tly and therefore cannot be treated as a vector expression. 
requires cas mg jj owever unpacked arrays can be assigned to packed arrays using 
bit-stream casting, as discussed in section 4.3.7 on page 91. 
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Assigning packed arrays to unpacked arrays 



assigning 
packed arrays to 
unpacked arrays 
requires casting 



A packed array cannot be directly assigned to an unpacked array. 
Even if the dimensions of the two arrays are identical, the packed 
array is treated as a vector, which cannot be directly assigned to an 
unpacked array, where each array element can be stored indepen- 
dent from other elements. However, the assignment can be made 
using a bit-stream cast operation. 



4.3.7 Copying arrays using bit-stream casting 



a bit-stream cast 
converts arrays 
to a temporary 
vector of bits 



A bit-stream cast temporarily converts an unpacked array to a 
stream of bits in vector form. The identity of separate elements 
within the array are lost — the temporary vector is simply a stream 
of bits. This temporary vector can then be assigned to another array. 
The destination array must be either a packed array or another bit- 
stream representation of an unpacked array. When the stream of 
bits is stored in the destination array, the identity of each element in 
the destination array. 



Bit-stream casting provides a mechanism for: 

• assigning an unpacked array to an unpacked array of a different 
size or layout 

• assigning an unpacked array to a packed array 

• assigning a packed array to an unpacked array 

Bit-stream casting can also be used to copy an unpacked structure 
to another unpacked structure that has a different layout, assign an 
unpacked structure to a packed structure, or assign a packed struc- 
ture to an unpacked structure. 

Bit-stream casting uses the SystemVerilog static cast operator. The 
casting requires that at least the destination array be represented as 
a user-defined type, using typedef . 

typedef int [3:0] [7:0] data__t; // unpacked type 
data_t a; 

int b [3:0] [3:0]/ // unpacked array 

a = data_t # (b) ; // assign unpacked array to 

// unpacked array of a 
// different size 
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The cast operation is effectively performed in three steps (these 
steps may be optimized internally by software tools). First, the two 
arrays are converted into temporary vector representations (a 
stream of bits). Second, the assignment is made as a vector to vec- 
tor assignment, following Verilog rules for any differences in the 
vector sizes represented by the temporary vectors. Finally, the tem- 
porary vector representation of the destination array is converted 
back to its unpacked representation. 



4.3.8 Arrays of arrays 

an array can mix It is common to have a combination of unpacked arrays and packed 

packed and arrays. Indeed, a standard Verilog memory array is actually a mix 

unpacked 0 f arra y types. The following example declares an unpacked array 
dimensions .v , . 

of 64-bit packed arrays: 



bit [63:0] mem [0:4095] 



This next example declares an unpacked array of 32-bit elements, 
where each element is a packed array, divided into 4 bytes: 

wire [3:0] [7:0] data [0:1023]; 



Indexing arrays of arrays 

unpacked When indexing arrays of arrays, unpacked dimensions are refer- 
dimensions are enced first, from the left-most dimension to the right-most dimen- 
indexed before s j on p ac k e( j dimensions (vector fields) are referenced second, from 
dimensions l e ft~ most dimension to the right-most dimension. Figure 4-5 
illustrates the order in which dimensions are selected in a mixed 
packed and unpacked multi-dimensional array. 



Figure 4-5: Selection order for mixed packed/unpacked multi-dimensional array 



logic [3:0] [7:0] mixed__array [0:7] [0:7] [0:7] ; 
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4.3,9 Using user-defined types with arrays 

arrays can User-defined types can be used as elements of an array. The follow- 
contain user- j n g example defines a user type for an unsigned integer, and 
defined types an unpacked array of 128 of the unsigned integers. 

typedef int unsigned uint; 

uint u_array [0:127]; // array of user types 

User-defined types can also be defined from an array definition. 
These user types can then be used in other array definitions, creat- 
ing a compound array. 

typedef bit [3:0] nibble; // packed array 
nibble [31:0] big__word; // packed array 

The preceding example is equivalent to: 

bit [31:0] [3:0] big_word; 

Another example of a compound array built up from user-defined 
types is: 

typedef bit [3:0] nibble; // packed array 
typedef nibble nib__array [0:3]; // unpacked 

nib_array compound_array [0:7]; // unpacked 

This last example is equivalent to: 

bit [3:0] compound_array [0:7] [0:3]; 



4.3.10 Passing arrays through ports and to tasks and functions 

In Verilog, a packed array is referred to as a vector, and is limited to 
a single dimension. Verilog allows packed arrays to be passed 
through module ports, or to be passed in or out of tasks and func- 
tions. Verilog does not allow unpacked arrays to be passed through 
module ports, tasks or functions. 

SystemVerilog SystemVerilog extends Verilog by allowing arrays of any type and 

allows unpacked any number of dimensions to be passed through ports or task/func- 
arrays as ports tion arguments . 
and arguments 
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To pass an array through a port, or as an argument to a task or func- 
tion, the port or task/function argument must also be declared as an 
array. Arrays that are passed through a port follow the same rules 
and restrictions as arrays that are assigned to other arrays, as dis- 
cussed in section 4.3.6 on page 90. 

module CPU (...); 

bit [7:0] lookup_table [0:255]; 

lookup il ( .LUT(lookup_table) ) ; 

endmodule 

module lookup (output bit [7:0] LUT [0:255]); 

initial load (LUT) ; //task call 

task load (inout bit [7:0] t [0:255]); 

endtask 

endmodule 

4.3.11 Arrays of structures and unions 

arrays can Packed and unpacked arrays can include structures and unions as 
contain elements in the array. In a packed array, the structure or union must 
structures or a i so packed. 
unions 

typedef struct packed { // packed structure 

int a ; 
byte b; 

} packet_t; 

packet_t [23:0] packet_array; // packed array 

// of 24 structures 



typedef struct { // unpacked structure 

int a; 
real b; 

} data_t; 



data_t data_array [23:0]; // unpacked array 

// of 24 structures 
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4.3.12 Arrays in structures and unions 

structures and Structures and unions can include packed or unpacked arrays. A 

unions can packed structure or union can only include packed arrays. 
contain arrays 

struct packed { // packed structure 

bit parity; 

bit [3:0] [ 7:0] data; // 2-D packed array 
} data_word; 

struct { 

bit da t already; 
byte data [0:3] ; 

} packet_t; 

4.3.13 Synthesis guidelines 

Arrays and assignments involving arrays are synthesizable. Specifi- 
cally: 

• Arrays declarations — Both unpacked and packed arrays are syn- 
thesizable. The arrays can have any number of dimensions. 

• Assigning values to arrays — synthesis supports assigning values 
to individual elements of an array, bit-selects or part-selects of an 
array element, array slices, or entire arrays. Assigning lists of lit- 
eral values to arrays is also synthesizable, including literals using 
the default keyword. 

• Copying arrays — Synthesis supports packed arrays directly 
assigned to packed arrays. Synthesis also supports unpacked 
arrays directly assigned to unpacked arrays of the same layout. 
Assigning any type of array to any type of array using bit-stream 
casting is also synthesizable. 

• Arrays in structures and unions — The use of arrays within struc- 
tures and unions is synthesizable. Unions must be packed, which 
means arrays within the union must be packed). 

• Arrays of structures or unions — Arrays of structures and arrays 
of unions are synthesizable (unions must be packed). A structure 
or union must be typed (using typedef) in order to define an 
array of the structure or union. 

• Passing arrays — Arrays passed through module ports, or as 
arguments to a task or function, is synthesizable. 



// unpacked structure 
// unpacked array of bytes 
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4.3.14 An example of using arrays 

The following example models an instruction register using a 
packed array of 32 instructions. Each instruction is a compound 
value, represented as a packed structure. The operands within an 
instruction can be signed or unsigned, which are represented as a 
union of two data types. The inputs to this instruction register are 
the separate operands, opcode, and a flag indicating if the operands 
are signed or unsigned. The model loads these separate pieces of 
information into the instruction register. The output of the model is 
the array of 32 instructions. 

Example 4-2: Using arrays of structures to model an instruction register 

typedef enum {ADD, SUB, MULT, DIV, SL, SR} opcode_t; 

typedef enum {UNSIGNED, SIGNED) operand_type_t ; 

typedef union packed { 

logic [31:0] u_data; 

bit signed [31:0] s_data; 

} data_t; 

typedef struct packed { 

opcode__t opc ; 

operand__type_t op_type ; 
data_t op_a ; 

data_t op_b ; 

} instr_t; 

module instruct ion_register ( 

output instr__t [0:31] instr__reg, // packed array of structures 

input data__t operand_a, 

input data__t operand_b, 

input operand_type_t op_type, 

input opcode_t opcode , 

input logic [4 : 0] write_j?ointer 

) ; 



always @ (writejpointer) begin 

instr_reg [write_pointer] .op__type = op_type; 
instr__reg [write_pointer] .opc = opcode; 

// use op__type to determine the operand data type stored 
// in the input operand union 
if (op_type == SIGNED) begin 

instr__reg [write_j?ointer] . op__a . s_data = operand_a . s_data ; 
instr_reg [write__pointer ] . op__b . s__data = operand_b . s__data ; 
end 
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else begin 

instr__reg [write_pointer] . op_a . u_data = operand_a . u_data ; 
instr_reg [write_pointer] ,op_b.u_data = operand_b.u_data; 

end 

end 

endmodule 



4.4 Array querying system functions 



special system SystemVerilog adds several special system functions for working 
functions for with arrays. These system functions allow writing verification rou- 
working with hnes that work with any size array. They may also be useful in 
arrays a h s tract models. 

The special system functions for working with arrays are: 

$dimensions (array__name) 

• Returns the number of dimensions in the array (returns 0 if 
the object is not an array) 

$left (array_name, dimension) 

• Returns the most-significant bit (msb) number of the speci- 
fied dimension. Dimensions begin with the number 1, starting 
from the left-most unpacked dimension. After the right-most 
unpacked dimension, the dimension number continues with 
the left-most packed dimension, and ends with the right-most 
packed dimension. For the array: 

bit [1:2] [7:0] word [0:3] [4:1] / 

$left (word, 1) will return 0 
$left (word, 2) will return 4 
$left (word, 3) will return 1 
$left (word, 4) will return 7 

$right (array_name, dimension) 

• Returns the least-significant bit (lsb) number of the specified 
dimension. Dimensions are numbered the same as with 
$left. 
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$low(array_name, dimension) 

• Returns the lowest bit number of the specified dimension, 
which may be either the msb or the lsb. Dimensions are num- 
bered the same as with $lef t. For the array: 

bit [7:0] word [1:4]; 

$low(word, 1) returns 1, and $low(word # 2) returns 0. 

$high (array_name , dimension) 

• Returns the highest bit number of the specified dimension, 
which may be either the msb or the lsb. Dimensions are num- 
bered the same as with $lef t. 

$size (array_name, dimension) 

• Returns the total number of elements in the specified dimen- 
sion (same as $high - $low + l). Dimensions are numbered 
the same as with $lef t. 

$ increment (array_name , dimension) 

• Returns 1 if $lef t is greater than or equal to $right, and -1 
if $lef t is less than $right. Dimensions are numbered the 
same as with $left. 

The dimension argument is optional. If not specified, it defaults to 
1, which represents the first dimension of the array, as with $lef t,. 

The following code snippet shows how some of these special array 
system functions can be used to increment through an array, with- 
out needing to hard code the size of each array dimension. 

bit [3:0] [7:0] array [0:1023]; 

int d = $ dimens ions (array) ; 

if (d > 0) begin // object is an array 
for (int j = $right (array, 1) ; 

j < $size (array, 1) ; 
j += $ increment (array, 1) ) 

begin 

... //do something 

end 



end 
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Synthesis guidelines 

These array query functions are synthesizable, provided that the 
dimension number argument is a constant, or is not specified at all. 
This is an exception to the general rule that synthesis compilers do 
not support the usage of system tasks or functions. The return value 
of these special array system functions can be determined statically 
at elaboration time, based on the declarations of the arrays. There- 
fore, synthesis compilers can calculate the function return values 
and treat them as constants for synthesis. 



4.5 The $bits “sizeof” system function 



$bits is similar to SystemVerilog adds a $bits system function, which returns how 
C’s sizeof many bits are represented by any expression. The expression can 
function con t a } n an y type of value, including packed or unpacked arrays, 
structures, unions, and literal numbers. The syntax of $bits is: 

$bits (expression) 

Some examples of using $bits are: 

bit [63:0] a; 

logic [63:0] b; 

wire [3:0] [7:0] c [0:15]; 

struct packed {byte tag; logic [31:0] addr;} d; 

• $bits (a) returns 64 

• $bits (b) returns 64 

• $bits (c) returns 512 

• $bits (d) returns 40 

• $bits(a+b) returns 128 

Synthesis guidelines 

The $bits system function is synthesizable. The return value of 
$bits can be determined statically at elaboration time, and is there- 
fore treated as a simple literal value for synthesis. 
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4.6 Dynamic arrays, associative arrays, sparse arrays and strings 



SystemVerilog adds classes to Verilog. SystemVerilog also adds 
new array types to Verilog that make use of classes and class meth- 
ods. These object-oriented array types include: 

• Dynamic arrays 

• Associative arrays 

• Sparse arrays 

• Strings (character arrays) 

These special array types are not synthesizable. 

Classes are not synthesizable, and are intended for use in verifica- 
tion routines and for modeling at very high levels of abstraction. 
The focus of this book is on writing models with SystemVerilog 
that are synthesizable. Therefore, SystemVerilog’s object oriented 
array types are only briefly covered in the following subsections. 
More details on these object-oriented array types can be found in 
the forthcoming companion book, SystemVerilog for Verification . 

Dynamic arrays 

dynamic arrays Dynamic arrays allow the size of the array to be increased or 
can change size decreased during simulation. A dynamic array is declared using an 
during run-time em pty se t 0 f [ ] brackets. For example: 

int d [] ; // dynamically sized array of ints 

Storage for a dynamic array is not allocated until the array is actu- 
ally created during run-time, and can be changed during run-time. 
SystemVerilog includes predefined methods to create dynamic 
arrays, and to dynamically change the size of these arrays. 

• new[] — a special function to create storage for a dynamic 
array. 

• size ( ) — a method that returns the size of a dynamic array. 

• delete () — a method to remove all storage for a dynamic 
array. 
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static arrays 
store all 
elements and 
have contiguous 
integer indices 



associative 
arrays only store 
the elements 
used and have 
non-contiguous 
indices of any 
data type 



For example: 
module test; 

int d [] ; // dynamically sized array of ints 

initial 

begin 

d = new [100] ; // allocate 100 elements 

d * new[d.size + 4] (d) ; // add 4 elements 

// to array 



end 

A more detailed explanation of dynamic arrays, the new function, 
and built-in methods can be found in the forthcoming companion 
book, SystemVerilog for Verification , along with full examples of 
using dynamic arrays. 

Associative arrays and sparse arrays 

The indices into fixed and dynamic arrays must be integer expres- 
sions. The indices for each dimension of the array must be a contig- 
uous set of integer values. For example, the array int i [0:3] will 
have the indices 0, 1, 2, and 3. In addition, packed arrays, unpacked 
arrays and dynamic arrays must allocate storage for all elements of 
an array. Even if only the first and 25th elements of an array are 
used, storage must still be allocated for all elements of the array. 

SystemVerilog adds a special associative array object class. Asso- 
ciative arrays can use any type of expression as the array indices, 
including enumerated types. The values of the indices into an asso- 
ciate array do not need to be contiguous values. The storage for 
each element of an associative array is not created until that ele- 
ment is accessed. This allows associative arrays to be used as 
sparse arrays . If only the first and 25th element of an associative 
array are used, then only those two elements will have storage allo- 
cated. SystemVerilog provides a number of built-in class methods 
for working with associative arrays. 

As with dynamic arrays, associative arrays are not synthesizable. 
Associative arrays are for verification and for representing models 
at a very high, non-synthesizable, level of abstraction. The forth- 
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coming companion book, SystemVerilog for Verification , presents 
the full syntax and usage of associative and sparse arrays. 

Strings 

SystemVerilog SystemVerilog includes a built-in class object for working with 
adds a string ASCII strings. The SystemVerilog string type is a dynamic array of 
class characters. A string type will automatically resize itself to the num- 
ber of characters stored in the string. A number of special string 
object methods are provided to work with strings. The forthcoming 
companion book, SystemVerilog for Verification , provides more 
information on SystemVerilog string arrays. 



4.7 Summary 



SystemVerilog adds the ability to represent complex data sets as 
single entities. Structures allow variables to be encapsulated into a 
single object. The structure can be referenced as a whole. Members 
within the structure can be referenced by name. Structures can be 
packed, allowing the structure to be manipulated as a single vector. 
SystemVerilog unions provide a way to model a single piece of 
storage at an abstract level, where the value stored can be repre- 
sented as any variable data type. 

SystemVerilog also extends Verilog arrays in a number of ways. 
With SystemVerilog, arrays can be assigned values as a whole. All 
of an array, or slices of one dimension of an array, can be copied to 
another array. The basic Verilog vector declaration is extended to 
permit multiple dimensions, in the form of a packed array. A 
packed array is essentially a vector that can have multiple sub 
fields. SystemVerilog also provides a number of new array query 
system functions that are used to determine the characteristics of 
the array. 

Chapter 10 contains a more extensive example of using structures, 
unions and arrays to represent complex data in a manner that is con- 
cise, intuitive and efficient, and yet is fully synthesizable. 




Chapter 5 

System Verilog Procedural 
Blocks, Tasks and Functions 



r he Verilog language provides a general purpose procedural 
block, called always, that is used to model a variety of hard- 
ware types as well as verification routines. Because of the general 
purpose application of the always procedural block, the design 
intent is not readily apparent. 

SystemVerilog extends Verilog by adding hardware type-specific 
procedural blocks that clearly indicate the designer’s intent. By 
reducing the ambiguity of the general purpose always procedural 
block, simulation, synthesis, formal checkers, lint checkers, and 
other EDA software tools can perform their tasks with greater accu- 
racy, and with greater consistency between different tools. 

SystemVerilog also provides a number of enhancements to Verilog 
tasks and functions. Some of these enhancements make the Verilog 
HDL easier to use, and others substantially increase the power of 
using tasks and functions for modeling large, complex designs. 

The topics covered in this chapter include: 

• Combinational logic procedural blocks 
• Latched logic procedural blocks 
• Sequential logic procedural blocks 
• Task and function enhancements 
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5,1 Verilog general purpose always procedural block 



an always The Verilog always procedural block is an infinite loop that 
procedural block repeatedly executes the statements within the loop. In order for sim- 
is an infinite loop u i a ti on time to advance, the loop must contain some type of time 
control or event control. This can be in the form of a fixed delay, 
represented with the # token, a delay until an expression evaluates 
as true, represented with the wait keyword, or a delay until an 
expression changes value, represented with the ® token. Verilog’s 
general purpose always procedural block can contain any number 
of time controls or event controls, and the controls can be specified 
anywhere within the procedural block. 

always 
begin 

wait (resetN == 0) // level -sensitive delay 
@(negedge clock) // edge -sensitive delay 
#2 t <= d; // time-based delay 

@(posedge clock) 

#1.5 q <= t; 

end 




Sensitivity lists 

an edge event An edge sensitive event control at the very beginning of an always 
control can be procedural block is typically referred to as the sensitivity list for 
uaacfasa that procedural block. Since no statement within the procedural 
y block can execute until the edge-sensitive event control is satisfied, 
the entire block is sensitive to changes on the signals listed in the 
event control. In the following example, the execution of state- 
ments in the procedural block are sensitive to changes on a and b. 

always @(a, b) // sensitivity list 

begin 

sum = a + b; 

diff = a - b; 

prod = a * b; 

end 

General purpose usage of always procedural blocks 

always can The Verilog always procedural block is used for general purpose 
represent any modeling. At the RTL level, the always procedural block can be 
type of logic use( j to mo del combinatorial logic (also referred to as combina - 
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tional logic), latched logic , and sequential logic . At more abstract 
modeling levels, an always procedural block can be used to model 
algorithmic logic behavior, without clearly representing the imple- 
mentation details of that behavior, such as an implicit state machine 
that performs a number of operations on data over multiple clock 
cycles. The same general purpose always procedural block is also 
used in testbenches to model clock oscillators and to perform other 
tasks that need to be repeated throughout the verification process. 

Inferring implementation from always procedural blocks 

tools must infer The multi-function role of the general purpose always procedural 
design intent block places a substantial burden on software tools such as synthe- 
from the s j s compilers and formal verification. It is not enough to execute the 

block’s contents statements within the procedural block. Synthesis compilers and 
formal verification tools must also try to deduce what type of hard- 
ware is being represented — combinational, latched or sequential 
logic. In order to infer the proper type of hardware implementation, 
synthesis compilers and formal tools must examine the statements 
and event controls within the procedural block. 

The following always procedural block is syntactically correct, but 
is not synthesizable. The procedural block will compile and simu- 
late without any compilation or run-time errors, but a synthesis 
compiler or formal verification tool would probably have errors, 
because the functionality within does not clearly indicate whether 
the designer was trying to model combinational, sequential or 
latched logic. 

always @(posedge clock) begin 
wait (IresetN) 
if (mode) ql = a + b; 
else ql = a - b; 

q2 <= ql | (q2 << 2) ; 
q2++ ; 
end 

In order to determine how the behavior of this example can be real- 
ized in hardware, synthesis compilers and formal tools must exam- 
ine the behavior of the code logic, and determine exactly when each 
statement will be executed and when each variable will be updated. 
A few, but not all, of the factors these tools must consider are: 

• What type of hardware can be inferred from the sensitivity list? 
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always 
procedural 
blocks 



combinational 

logic 



• What can be inferred from if ...else and case decisions? 

• What can be inferred from assignment statements and the opera- 
tors within those statements? 

• Is every variable written to by this procedural block updated in 
each loop of the always procedural block? That is, is there any 
implied storage within the procedural block’s functionality that 
would infer latched behavior? 

• Are there assignments in the procedural block that never actually 
update the variable on the left-side? (In the preceding example 
the q2++ statement will never actually increment q2, because the 
line before is a nonblocking assignment that updates its left-hand 
side, which is q2, after the ++ operation). 

• Could other procedural blocks elsewhere in the same module 
affect the variables being written into by this procedural block? 

In order to reduce the ambiguity of what hardware should be 
inferred from the general purpose always procedural block, syn- 
thesis compilers place a number of restrictions and guidelines on 
the usage of always blocks. The rules for synthesis are covered in 
the IEEE 1364.1 standard for Verilog Register Transfer Level Syn- 
thesis 1 . Some highlights of these restrictions and guidelines are: 

To represent combinational logic with a general purpose always 
procedural block: 

• The always keyword must be followed by an edge-sensitive 
event control (the @ token). 

• The sensitivity list of the event control cannot contain posedge 
or negedge qualifiers. 

• The sensitivity list should include all inputs to the procedural 
block. Inputs are any signal read by the procedural block, where 
that signal receives its value from outside the procedural block. 

• The procedural block cannot contain any other event controls. 

• All variables written to by the procedural block must be updated 
for all possible input conditions. 

• Any variables written to by the procedural block cannot be writ- 
ten to by any other procedural block. 



1 . 1364.1-2002 IEEE Standard for Verilog Register Transfer Level Synthesis. See page xxvii. 
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latched logic To represent latched logic with a general purpose always proce- 
dural block: 

• The always keyword must be followed by an edge-sensitive 
event control (the @ token). 

• The sensitivity list of the event control cannot contain posedge 
or negedge qualifiers. 

• The sensitivity list should include all inputs to the procedural 
block. Inputs are any signal read by the procedural block, where 
that signal receives its value from outside the procedural block. 

• The procedural block cannot contain any other event controls. 

• At least one variable written to by the procedural block must not 
be updated for some input conditions. 

• Any variables written to by the procedural block cannot be writ- 
ten to by any other procedural block. 

sequential logic To represent sequential logic with a general purpose always proce- 
dural block: 

• The always keyword must be followed by an edge-sensitive 
event control (the @ token). 

• All signals in the event control sensitivity list must be qualified 
with posedge or negedge qualifiers. 

• The procedural block cannot contain any other event controls. 

• Any variables written to by the procedural block cannot be writ- 
ten to by any other procedural block. 

modeling Since Verilog always procedural blocks are general purpose pro- 
guidelines cedural blocks, these synthesis guidelines cannot be enforced other 
en/brcedfora ^ s °ft ware tools. Simulation tools, for example, must allow 
general purpose alwa T s procedural blocks to be used in a variety of ways, and not 
procedural block just within the context imposed by synthesis compilers. Because 
simulation and synthesis are not enforcing the same semantic rules 
for always procedural blocks, mismatches in simulation and syn- 
thesis results can occur if the designer does not follow strict, self- 
imposed modeling guidelines. Formal verification tools may also 
require that self-imposed modeling guidelines be followed, to pre- 
vent mismatches in simulation results and formal verification 
results. 
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5,2 SystemVerilog specialized procedural blocks 



SystemVerilog adds three specialized procedural blocks to reduce 
the ambiguity of the Verilog general purpose always procedural 
block. These are: always _comb, alwayslatch and always _f f . 

specialized These specialized procedural blocks are infinite loops, the same as 
procedural a n always procedural block. However, the procedural blocks add 
blocks are syntactic and semantic rules that enforce a modeling style compati- 
syn esiza e ^ w jth the IEEE 1364.1 synthesis standard. These specialized pro- 
cedural blocks are used to model synthesizable RTL logic. 

The specialized always_comb, always_latch and always_ff 
procedural blocks indicate the design intent. Software tools do not 
need to infer from context what the designer intended, as must be 
done with the general purpose always procedural block. If the con- 
tent of a specialized procedural block does not match the rules for 
that type of logic, software tools can issue warning messages. 

By using always_comb, always_latch, and always_f f proce- 
dural blocks, the engineer’s intent is clearly documented for both 
software tools and for other engineers who review or maintain the 
model. Note, however, that SystemVerilog does not require soft- 
ware tools to verify that a procedural block’s contents match the 
type of logic specified with the specific type of always procedural 
block. Warning messages regarding the procedural block’s contents 
are optional. 

5.2.1 Combinational logic procedural blocks 

always_comb The alwayscomb procedural block is used to indicate the intent to 
represents model combinational logic. 
combinational 

logic alwayscomb 
if (Imode) 
y = a + b; 

else 

y = a - b; 

alwaysjcomb Unlike the general purpose always procedural block, it is not nec- 
*?f e . rs *! s essary to specify a sensitivity list with alwaysjcomb. A combina- 
sensitivity list ti ona l logic sensitivity list can be automatically inferred, because 
software tools know that the intent is to represent combinational 
logic. This inferred sensitivity list includes every signal that is read 



specific 
procedural block 
types document 
design intent 
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by the procedural block, if the signal receives its value from outside 
the procedural block. Temporary variables that are only assigned 
values using blocking assignments, and are only read within the 
procedural block, are not included in the sensitivity list. System- 
Verilog also includes in the sensitivity list any signals read by func- 
tions called from the procedural block, except for temporary 
variables that are only assigned and read within the function. The 
rules for inferring the sensitivity of bit selects, part selects and array 
indexing are described in the SystemVerilog LRM. 

Following the semantic rules for always__coxnb, all software tools 
will infer the same sensitivity list. This eliminates the risk of mis- 
matches that can occur with a general purpose always procedural 
block, should the designer inadvertently specify an incorrect sensi- 
tivity list. 

shared variables The always_comb procedural block also requires that variables on 
are prohibited the left-hand side of assignments cannot be written to by any other 
procedural block. This restriction prevents a form of shared vari- 
able usage that does not behave like combinational logic. The 
restriction matches the guidelines for synthesis, and ensures that all 
software tools — not just synthesis — are enforcing the same model- 
ing guideline. 

Non-ambiguous design intent 

tools do not An important advantage of always_comb over the general purpose 
need to infer always procedural block is that when always_comb is specified, 
design intent d es jg ner ’ s intent is clearly stated. Software tools no longer need 
to examine the contents of the procedural block to try to infer what 
type of logic the engineer intended to model. Instead, with the 
intent of the procedural block explicitly stated, software tools can 
examine the contents of the procedural block and issue warning 
messages if the contents do not represent combinational logic. 

In the following example with a general purpose always proce- 
dural block, a software tool cannot know what type of logic the 
designer intended to represent, and consequently will infer that 
latched logic was intended, instead of combinational logic. 

always @(a, b) 
if (b) y = a; 
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With SystemVerilog, this same example could be written as fol- 
lows: 

alwayscomb 

if (b) y = a; 

Software tools can then tell from the always_comb keyword that 
the designer’s intent was to model combinational logic, and can 
issue a warning that a latch would be required to realize the proce- 
dural block’s functionality in hardware. 

The correct way to model the example above as combinational 
logic would be to include an else branch so that the output y 
would be updated for all conditions of b. If the intent were that y 
did not change when b was false, then the correct way to model the 
logic would be to use an always_latch procedural block, as 
described in section 5.2.2 on page 1 15 of this chapter. 

Automatic evaluation at time zero 

always_comb The always_comb procedural block also differs from generic 
ensures outputs always procedural blocks in that an always comb procedural 
consistent!!) automatically trigger once at simulation time zero, after 
input values initial anc * always procedural blocks have been activated. 

This automatic evaluation occurs regardless of whether or not there 
are any changes on the signals in the inferred sensitivity list. This 
special semantic of always__comb ensures that the outputs of the 
combinational logic are consistent with the values of the inputs to 
the logic at simulation time zero. This automatic evaluation at time 
zero can be especially important when modeling with 2-state vari- 
ables, which, by default, begin simulation with a logic 0. A reset 
may not cause events on the signals in the combinational logic sen- 
sitivity list. If there are no events, a general-purpose always proce- 
dural block will not trigger and, therefore, the output variables will 
not be updated. 

The following example illustrates this difference between 
always comb and general-purpose always procedural blocks. 
The model represents a simple Finite State Machine modeled using 
enumerated types. The three possible states are WAIT, LOAD and 
STORE. When the state machine is reset, it returns to the WAIT state. 
The combinational logic of the state machine decodes the current 
state, and if the current state is wait, sets the next state to be load. 
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On each positive edge of clock, the state sequence logic will set 
the State variable to the value of the NextState variable. 

The code listed in example 5-1 models this state machine with Ver- 
ilog’s general purpose always procedure. 

Example 5-1 : A state machine modeled with an always procedural block 

module controller (output logic read, write, 

Input instr_t instruction, 

input wire clock, resetN) ; 

enum {WAIT, LOAD, STORE} State, NextState; 

always ©(posedge clock, negedge resetN) 
if (! resetN) State <= WAIT; 
else State <= NextState; 

always @ (State) ^ 

case (State) 

WAIT: NextState = LOAD; 

LOAD: NextState = STORE; 

STORE: NextState = WAIT; 

endcase 

... // set controller outputs based on current State 

endmodule 



Only triggers when state 
changes value 



There is a simulation subtlety in example 5-1. At simulation time 
zero, enumerated variables default to the first value in the enumer- 
ated list. Therefore, both the State variable and the NextState 
variable default to the value of wait. On a positive edge of clock, 
the state sequence logic will set State to NextState. Since both 
variables have the same value, however, State does not actually 
change. Since there is no change on State, the always @ (State) 
procedural block does not trigger, and the NextState variable 
does not get updated to a new value. The simulation of this model is 
locked, because the State and the NextState variables have the 
same values. This problem continues to exist even when reset is 
applied. A reset sets State to the value of WAIT, which is the same 
as its current value. Since State does not change, the always 
@ (State) procedural block does not trigger, perpetuating the 
problem that state and NextState have the same value. 
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Example 5-2, below, makes one simple change to this example. The 
always ©(State) is replaced with always__comb. The 
always_comb procedural block will infer a sensitivity list for all 
external variables that are read by the block, which in this example 
is state. Therefore, the always_comb infers the same sensitivity 
list as in example 5-1: 

Even though the sensitivity lists are the same, there is an important 
difference between always_comb and using always @ (State). 
An alwayscomb procedural block automatically executes one 
time at simulation time zero, after all procedural blocks have been 
activated. In this example, this means that at simulation time zero, 
NextState will be updated to reflect the value of State at time 
zero. When the first positive edge of clock occurs, State will 
transition to the value of NextState, which is a different value. 
This will trigger the always_comb procedure, which will then 
update NextState to reflect the new value of State. Using 
always comb, the simulation lock problem illustrated in example 
5-1 will not occur. 

Example 5-2: A state machine modeled with an always_comb procedural block 

module controller (output logic read, write, 

input instr__t instruction, 

input wire clock, resetN) ; 

enum {WAIT, LOAD, STORE} State, NextState; 

always @(posedge clock, negedge resetN) 
if ( ! resetN) State <= WAIT; 
else State <= NextState; 

always_comb ^ 

case (State) 

WAIT: NextState = LOAD; 

LOAD: NextState - STORE; 

STORE: NextState = WAIT; 

endcase 

... // set controller outputs based on current State 

endmodule 



Infers @ (State) — block 
automatically executes once 
at time zero, even if not 
triggered 
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always_comb versus always @* 

The Verilog-2001 standard added the ability to specify a wildcard 
for the @ event control, using either @* or @(*). The primary 
intent of the wildcard is to allow modeling combinational logic sen- 
sitivity lists without having to specify all the signals within the list. 

always @* // combinational logic sensitivity 

if (Imode) 
y = a + b; 

else 

y = a - b; 

The inferred sensitivity list of Verilog’s @* is a convenient shortcut, 
and can simplify modeling complex procedural blocks with combi- 
national logic. However, the @* construct does not require that the 
contents of the general-purpose always procedural block adhere to 
synthesizable combinational logic modeling guidelines. 

The specialized always_comb procedural block not only infers the 
combinational logic sensitivity list, but also restricts other proce- 
dural blocks from writing to the same variables so as to help ensure 
true combinatorial behavior. In addition, always_comb executes 
automatically at time zero, to ensure output values are consistent 
with input values, whereas the @* sensitivity list will only trigger if 
at least one of the inferred signals in the list changes. This differ- 
ence was illustrated in examples 5-1 and 5-2, above. 

@* can be used The @ event control can be used both at the beginning of a proce- 
incorrectly dural block, as a sensitivity list, as well as to delay execution of any 
statements within a procedural block. Synthesis guidelines do not 
support combinational event controls within a procedural block. 
Since @* is merely the event control with a wildcard to infer the sig- 
nals in its event control list, it is syntactically possible to use (or 
misuse) @* within a procedural block, where it cannot be synthe- 
sized. 

Another important distinction between @* and alwayscomb is in 
the sensitivity lists inferred. The Verilog standard defines that @* 
will infer sensitivity to all variables read in the statement or state- 
ment group that follows the @*. When used at the very beginning of 
a procedural block, this effectively infers sensitivity to all signals 
read within that procedural block. If a procedural block calls a fimc- 



@* sensitivity 
list may not be 
complete 



always @* does 
not have 
combinational 
logic semantics 




114 



SystemVerilog for Design 



tion, @* will only infer sensitivity to the arguments of the task/func- 
tion call. 

always_comb alwayscomb is defined to infer sensitivity to all signals read 

sensitivity list within the procedural block, plus any variables read within func- 
includes s&na/s tions that are called by the procedural block. This allows a more 
functions structu red coding style to be easily used in procedural blocks that 
contain a large amount of combinational logic. 

A common problem in large designs is that the amount of code in a 
combinational procedural block can become cumbersome. One 
solution to prevent the size of a combinational procedural block 
from getting too large, is to partition the logic into multiple proce- 
dural blocks. This partitioning, however, can lead to convoluted 
spaghetti code, where many signals propagate through several pro- 
cedural blocks. Another solution is to keep the combinational logic 
within one procedural block, but break the logic down to smaller 
sub-blocks using functions. Since functions synthesize to combina- 
tional logic, this is an effective method of structuring the code 
within large combinational procedural blocks. 

The Verilog @* places a limitation on the use of functions to struc- 
ture large blocks of combinational logic. The sensitivity list 
inferred by always @* only looks at the signals read directly by the 
always procedural block. It does not infer sensitivity to the signals 
read from within any functions called by the procedural block. 
Therefore, each function call must list all signals to be read by each 
function as inputs to the function, and each function definition must 
list these signals as formal input arguments. If, as the design 
evolves, the signals used by a function should change, then this 
change must be made in both the function formal argument list and 
from where the function is called. This additional coding and code 
management reduces the benefit of using functions to structure 
large combinational procedural blocks. 

SystemVerilog’s always_coxnb procedural block eliminates this 
limitation of @*. An always_comb procedural block is sensitive to 
both the signals read within the block and the signals read by any 
function called from the block. This allows a function to be written 
without formal arguments. If during the design process, the signals 
that need to be referenced by the function change, no changes need 
to be made to the function formal argument list or to the code that 
called the function. 
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The following example illustrates the difference in sensitivity lists 
inferred by @* and always_comb. In this example, the procedural 
block using @* will only be sensitive to changes on data. The 
always_comb procedure will be sensitive to changes on data, 
sel, c, d and e. 

always @* begin 

al = data << 1; 
bl = decode ( ) ; 

end 

always^coinb begin ◄ 

a2 = data << 1; 
b2 = decode ( ) ; 

end 



Infers 

©(data, sel, c, d, e) 



Infers @ (data) 



function decode; // function with no inputs 
begin 

case (sel) 

2'b01: decode = d | e; 

2'blO: decode = d & e; 

default: decode = c; 

endcase 

end 

endfunction 



5.2.2 Latched logic procedural blocks 

alwaysjatch The alwayslatch procedural block is used to indicate that the 
represents intent of the procedural block is to model latched-based logic. As 
latched logic a 2.wayB_comb, always__latch infers its sensitivity list. 

always_latch 

if (enable) q <= d; 



alwaysjatch 
has the same 
semantics as 
alwaysjcomb 



An always_latch procedural block follows the same semantic 
rules as with always_comb. The rules for what is to be included in 
the sensitivity list are the same for the two types of procedural 
blocks. Variables written in an alwaysJLatch procedural block 
cannot be written by any other procedural block. The 
always_latch procedural blocks also automatically execute once 
at time zero, in order to ensure that outputs of the latched logic are 
consistent with the input values at time zero. 
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tools can verify What makes always_latch different than always comb is that 
alwaysjatch software tools can determine that the designer’s intent is to model 

contents latched logic, and perform different checks on the code within the 
reoresent 

latched logic P roce dural block than the checks that would be performed for com- 
binational logic. For example, with latched logic, the variables rep- 
resenting the outputs of the procedural block do not need to be set 
for all possible input conditions. In the example above, a software 
tool could produce an error or warning if always_comb had been 
used, because the if statement without a matching else branch 
infers storage that combinational logic does not have. By specifying 
always_latch, software tools know that the designer’s intent is to 
have storage in the logic of the design. 

An example of using always_latch procedural blocks 

The following example illustrates a 5-bit counter that counts from 0 
to 31. An input called ready controls when the counter starts 
counting. The ready input is only high for a brief time. Therefore, 
when ready goes high, the model latches it as an internal enable 
signal. The latch holds the internal enable high until the counter 
reaches a full count of 31, and then clears the enable, preventing 
the counter from running again until the next time the ready input 
goes high. 

Example 5-3: Latched input pulse using an always_latch procedural block 

module register__reader (input elk, ready, resetN, 

output logic [4:0] read__pointer 
) ; 



logic enable; // internal enable signal for the counter 
logic overflow; // internal counter overflow flag 

always_latch begin // latch the ready input 
if (! resetN) 
enable <= 0; 
else if (ready) 
enable <= 1; 
else if (overflow) 
enable <= 0; 

end 

always @(posedge elk, negedge resetN) begin // 5-bit counter 
if (! resetN) 

{ overflow, read_j?ointer} <= 0; 
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else if (enable) 

{overflow, read_pointer} <= read_pointer + 1; 

end 

endmodule 



5.2.3 Sequential logic procedural blocks 

always Jf The always_ff specialized procedural block indicates that the 

represents designer’s intent is to model synthesizable sequential logic behav- 
sequential logic j or 

alwaysff @(posedge clock, negedge resetN) 
if (! resetN) q <= 0; 
else q <= d; 

A sensitivity list must be specified with an alwaysf f procedural 
block. This allows the engineer to model either synchronous or 
asynchronous set and/or reset logic, based on the contents of the 
sensitivity list. 

By using always_f f to model sequential logic, software tools do 
not need to examine the procedural block’s contents to try to infer 
the type of logic intended. With the intent clearly indicated by the 
specialized procedural block type, software tools can instead exam- 
ine the procedural block’s contents and warn if the contents cannot 
be synthesized as sequential logic. As with always_comb and 
always_latch, these additional semantic checks on an 
always_f f procedural block’s contents are optional. 

Sequential logic sensitivity lists 

The always__f f procedural block requires that every signal in the 
sensitivity list must be qualified with either posedge or negedge. 
This rule helps ensure that simulation results will match synthesis 
results. An always_f f procedural block also prohibits using event 
controls anywhere except at the beginning of the procedural block. 
Event controls within the procedural block do not represent a sensi- 
tivity list for the procedural block, and are not allowed. These rules 
for sequential logic sensitivity lists follow the modeling guidelines 
specified in the IEEE 1364.1 Verilog synthesis standard. 



always_ff 
enforces 
synthesizable 
sensitivity lists 



tools can verify 
that always Jf 
contents 
represent 
sequential logic 
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5.2.4 Synthesis guidelines 

The specialized always_comb, always_latch, and always_ff 
procedural blocks are synthesizable. These specialized procedural 
blocks are a better modeling choice than Verilog’s general purpose 
always procedural block whenever a model is intended to be used 
with simulation and synthesis tools. The specialized procedural 
blocks require simulators and other software tools to check for rules 
that are required by synthesis compilers. The use of always comb, 
always_latch, and always_f f procedural blocks can help elim- 
inate potential modeling errors early in the design process, before 
models are ready to synthesize. 



5.3 Enhancements to tasks and functions 



SystemVerilog makes several enhancements to Verilog tasks and 
functions. These enhancements make it easier to model large 
designs in an efficient and intuitive manner. 

5.3.1 Static and automatic storage in tasks and functions 

Verilog-1995 In the Verilog-1995 standard, tasks and functions are always static 
has static tasks in nature. This means that for each instance of a task or function, 
and functions s t ora g e f or the formal arguments and internal variables of the task 
or function are only allocated once. All calls to the task or function 
share the same storage. Each new call overwrites the values of the 
previous call. 

Fully automatic tasks and functions 

Verilog-2001 The Verilog-2001 standard adds automatic tasks and functions, 
adds automatic declared using the automatic keyword, which immediately fol- 

tfuncttons ^ ows task or function keyword. With automatic tasks and 
functions, all storage is allocated each time the task or function is 
called. For tasks, which can take simulation time to execute, this 
means a task can be called again, while a previous call is still exe- 
cuting. This capability is referred to as re-entrant tasks. For func- 
tions, which execute in zero time, automatic functions can call 
themselves recursively. Each recursive call to the function places 
the storage of the previous call on a stack. The values from the 




Chapter 5: SystemVerilog Procedural Blocks, Tasks and Functions 



119 



stack are retrieved when the current call exits, allowing the previ- 
ous call to continue with its own, unique storage. 



Mixed storage in tasks and functions 

SystemVerilog 
allows a mix of 
static and 
automatic 



SystemVerilog also permits an automatic task or function to con- 
tain static storage. This mixture of storage is primarily beneficial in 
verification. Static storage in an automatic task or function implies 
that multiple calls to the task or function are sharing the same stor- 
age, which infers multiple drivers to that element. Static storage in 
an automatic task or function should generally be avoided in mod- 
els that are to be synthesized. 

Section 2.8 on page 32 discusses declaring static and automatic 
variables, and provides examples of using a mixture of static and 
automatic storage in tasks and functions. 



SystemVerilog adds the ability to explicitly declare automatic stor- 
age within a static task or function, or any procedural block. One 
advantage of automatic variables in a task or function is that when 
in-line initialization is used, the initial value is assigned each time 
the task or function is called. If the variable were static, then the ini- 
tial value would only be assigned once, prior to the start of simula- 
tion. 



5.3.2 Implicit task and function statement grouping 



begin... end 
groups multiple 
statements 



In Verilog, multiple statements within a task or function must be 
grouped using begin.. .end. Tasks also allow multiple statements 
to be grouped using fork... join. 



SystemVerilog SystemVerilog simplifies task and function definitions by not 
infers requiring the begin.. .end grouping for multiple statements. If the 
begin... end g r0U pj n g j s omitted, multiple statements within a task or function 
are executed sequentially, as if within a begin.. .end block. 



function int add_and_inc (int a, b) ; 
add_and_inc = a + b; 
return ++add__and_inc; 
endfunction 
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5.3.3 Returning function values 



functions create 
an implied 
variable of the 
same name and 
type 



function int add_and_inc (input int a, b) ; 
add__and__inc = a + b; 
add_and__inc = add_and_inc + 1; 
endfunction 



In Verilog, the function name itself is an inferred variable that is the 
same data type as the function. The return value of a function is set 
by assigning a value to the name of the function. A function exits 
when the execution flow reaches the end of the function. The last 
value that was written into the inferred variable of the name of 
function is the value returned by the function. 



SystemVerilog adds a return statement, which allows functions to 
return a value using return, as in C. 

function int add_and_inc (input int a, b) ; 

return (a + b + 1 ) ; 
endfunction 



The parenthesis are not required in a return statement, but can help 
with readability when the return value is a compound expression. 



return has 
priority over 
returning the 
value in the 
function name 



To maintain backward compatibility with Verilog, the return value 
of a function can be specified using either the return statement or 
by assigning to the function name. The return statement takes 
precedence. If a return statement is executed, that is the value 
returned. If the end of the function is reached without executing a 
return statement, then the last value assigned to the function name 
is the return value, as it is in Verilog. Even when using the return 
statement, the name of the function is still an inferred variable, and 
can be used as temporary storage before executing the return 
statement. For example: 



function int add_and_inc (input int a, b) ; 
add_and_inc = a + b; 
return (++add_and_inc) ; 
endfunction 



5.3.4 Returning before the end of tasks and functions 

reach the%rid of * n Verilog, a tas ^ or function exits when the execution flow reaches 
a task or the end, which is denoted by endtask or endfunction. In order 
function to exit to exit before the end a task or function is reached using Verilog, 
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conditional statements such as if.. .else must be used to force the 
execution flow to jump to the end of the task or function. A task can 
also be forced to jump to its end using the disable keyword, but 
this will affect all currently running invocations of a re-entrant task. 
The following example requires extra coding to prevent executing 
the function if the input to the function is less than or equal to 1. 

function automatic int log2 (input int n) ; 

if (n <=1) 
log2 = 1; 

else begin // skip this code when n<=l 
log2 = 0; 

while (n > 1) begin 
n = n/2; 
log2 = log2+l; 

end 

end 

endf unction 

the return The SystemVerilog return statement can be used to exit a task or 
statement can function at any time in the execution flow, without having to reach 
be used to exit en( j 0 f task or function. 
before the end 

function automatic int log2 (input int n) ; 

if (n <=1) return 1; // abort function 

log2 = 0; 

while (n > 1) begin 

n = n/2; 
log2++; 

end 

endfunction 

Using return to exit a task or function before the end is reached 
can simplify the coding within the task or function, and make the 
execution flow more intuitive and readable. 

5.3.5 Void functions 

Verilog functions In Verilog, functions must have a return value. If no return value is 
must return a specified, static functions return the value of the previous call to the 
vaiue function, and automatic functions will return the default uninitial- 
ized value for the data type of the function. 

void functions SystemVerilog adds a void data type, similar to C. Functions can 
do not return a be explicitly declared as a void data type, indicating that there is 
vaiue 
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no return value from the function. Void functions are called as 
statements, like tasks, but have the syntax and semantic restrictions 
of functions. For example, functions cannot have any type of delay 
or event control, and cannot use nonblocking assignment state- 
ments. Another benefit of void functions is that they overcome the 
limitation that functions cannot call tasks. A function can call other 
functions, however. A void function is called in the same way as a 
task, since there is no return value. Functions can call void func- 
tions, and accomplish the same structured coding style of using 
tasks. 

Another SystemVerilog enhancement is that functions can have 
output and inout formal arguments. This allows a void function, 
which has no return value, to still propagate changes to the scope 
that called the function. Function formal arguments are discussed in 
more detail later in this chapter, in section 5.3.7 on page 124. 

typedef struct { 

bit valid; 

bit [ 7:0] check; 
bit [63:0] data; 

} packet_t; 

function void fill_packet ( 
input logic [63:0] data_in, 
output packet_t data__out ) ; 

data_out . data = data_in; 
for (int i=0; i<=7; i++) 

dat a_out. check [i] = A data_in [ (8*i) + : 8] ; 
data_out .valid = 1; 

endf unction 



Synthesis guidelines 



In synthesizable models, use void functions in place of tasks. 
TIP 



An advantage of void functions is that they can be called like a task, 
but must adhere to the restrictions for function contents. These 
restrictions, such as the requirement that functions cannot contain 
any event controls, help ensure proper synthesis results. 
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5.3.6 Passing task/function arguments by name 

Verilog passes When a task or function is called, Verilog only allows values to be 
argument values passed to the task or function in the same order in which the formal 
by position arguments 0 f the task or function are defined. Unintentional coding 
errors can occur if values are passed to a task or function in the 
wrong order. In the following example, the order in which the argu- 
ments are passed to the divide function is important. In the call to 
the function, however, it is not apparent whether or not the argu- 
ments are in the correct order. 

always @(posedge clock) 
result <= divide (b, a); 

function int divide (input int numerator, 

denominator) ; 

if (denominator == 0) begin 

$display( "Error ! divide by zero"); 
divide = 0; 

end 
else 

divide = numerator / denominator; 

endfunction 

SystemVerilog adds the ability to pass argument values to a task or 
function using the names of formal arguments, rather than the order 
of the formal arguments. Named argument values can be passed in 
any order, and will be explicitly passed through the specified for- 
mal argument. The syntax for named argument passing is the same 
as Verilog’s syntax for named port connections to a module 
instance. 

With SystemVerilog, the call to the function above can be coded as: 

// SystemVerilog style function call 
always @(posedge clock) 

result <= divide ( .denominator (b) , 

.numerator (a) ); 

Using named argument passing removes any ambiguity as to which 
formal argument of each value is to be passed. The code for the task 
or function call clearly documents the designer’s intent, and 
reduces the risk of inadvertent design errors that could be difficult 
to detect and debug. 



named 
argument 
passing can 
reduce errors 



SystemVerilog 
can pass 
argument values 
by name 
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5.3.7 Enhanced function formal arguments 

Verilog functions In Verilog, functions can only have inputs. The only output from a 

can only have Verilog function is its single return value. 
inputs 

// Verilog style function formal arguments 
function [63:0] add (input [63:0] a, b) ; 

endf unction 

SystemVerilog SystemVerilog allows the formal arguments of functions to be 
functions can declared as input, output or inout, the same as with tasks. This 
have inputs and g rea tly extends what can be modeled using functions, by allowing 
p s the function to have any number of outputs, in addition to the func- 
tion return value. 

The following code snippet shows a function that returns the result 
of an addition operation, plus an output formal argument that indi- 
cates if the addition operation resulted in an overflow. 

// SystemVerilog style function formal args 
function [63:0] add (input [63:0] a, b, 

output overflow) ; 

{overflow, add} = a + b; 

endfunction 

Restrictions on calling functions with outputs 

In order to prevent undesirable — and unsynthesizable — side 
effects, SystemVerilog restricts from where functions with output 
or inout arguments can be called. A function with output or inout 
arguments can not be called from: 

• an event expression. 

• an expression within a procedural continuous assignment. 

• an expression that is not within a procedural statement. 

5.3.8 Functions with no formal arguments 

SystemVerilog Verilog allows a task to have any number of formal arguments, 
functions can including none. However, Verilog requires that functions have at 
have no j east one j n p Ut f orma j argument, even if the function never uses the 
^ value of that argument. SystemVerilog allows functions with no 
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formal arguments, the same as with Verilog tasks. An example of 
using functions without arguments, and the benefits this style can 
offer, is presented in the latter part of section 5.2.1, under 
always_comb versus @*, on page 1 13. 



5.3.9 Default formal argument direction and type 

In Verilog, the direction of each formal argument to a task or func- 
tion must be explicitly declared as an input for functions, or as 
input, output, or inout for tasks. A comma-separated list of 
arguments can follow a direction declaration. Each argument in the 
list will be the last direction declared. 

function integer compare (input integer a, 

input integer b) ; 



endf unction 



task my task (input a, b, output yl, y2) ; 
endtask 

SystemVerilog simplifies the task and function declaration syntax, 
by making the default direction input. Until a formal argument 
direction is declared, all arguments are assumed to be inputs. Once 
a direction is declared, subsequent arguments will be that direction, 
the same as in Verilog. 

function int compare (int a, b); 

endfunction 

// a and b are inputs, yl and y2 are outputs 
task my task (a, b # output yl, y2) / 

endtask 

the default In Verilog, each formal argument of a task or function is assumed 
formal argument to be reg data type, unless explicitly declared as another variable 
data type is logic type. SystemVerilog makes the default data type for task or func- 
tion arguments the logic type. Since logic is synonymous with 
reg, this is fully compatible with Verilog. 



the default 
formal argument 
direction is input 
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5.3.10 Default formal argument values 

each formal SystemVerilog allows an optional default value to be defined for 
argument can each formal argument of a task or function. The default value is 
have a specified using a syntax similar to setting the initial value of a vari- 

able. In the following example, the formal argument count has a 
default value of 0, and step has a default value of 1. 

function int incrementor (int count=0, step=l) ; 
incrementor = count + step; 

endfunction 

When a task or function is called, it is not necessary to pass a value 
to the arguments that have default argument values. If nothing is 
passed into the task or function for that argument position, the 
default value is used for that call of the task or function. In the call 
to the incrementor function below, only one value is passed into 
the function, which will be passed into the first formal argument of 
the function. The second formal argument, step, will use its 
default value of 1. 

always @(posedge clock) 

result = incrementor ( data_bus ) ; 



|Y -== ^p Default formal argument values allow task or function calls to 
p only pass values to the arguments unique to that call. 



a call to a task 
or function can 
leave some 
arguments 
unspecified 



Specifying default argument values allows a task or function to be 
defined that can be used in multiple ways. In the preceding exam- 
ple, if the function to increment a value is called with just one argu- 
ment, its default is to increment the value passed in by one. 
However, the function can also be passed a second value when it is 
called, where the second value specifies the increment amount. 



SystemVerilog also changes the semantics for calling tasks or func- 
tions. Verilog requires that a task or function call have the exact 
same number of argument expressions as the number of task/func- 
tion formal arguments. SystemVerilog allows the task or function 
call to have fewer argument expressions than the number of formal 
arguments, as in the preceding example. 
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A task/function formal argument must have a default value in 
order to leave the argument unspecified in the task/function call. 

If a task or function call does not pass a value to an argument of the 
task or function, then the formal definition of the argument must 
have a default value. An error will result if a formal argument with- 
out a default value is not passed in a value. 

5.3.11 Arrays, structures and unions as formal arguments 

formal 
arguments can 
be structures or 
arrays 



task fill_packet ( 

input bit [7:0] data_in [0:7], // array arg 

output packet_t data__out ) ; // structure arg 

for (int i=0 ; i<=7; i++) begin 

data_out .data [ (8*i) + : 8] = data_in[i]; 
data_out . check [i] = A data_in[i]; 

end 

data_out .valid = 1; 

endtask 



SystemVerilog allows arrays, structures or unions to be passed in or 
out of tasks and functions. To do so, the formal argument must be 
defined as an array, structure or union. For example: 

typedef struct packed { 
bit valid; 
bit [ 7:0] check; 
bit [63:0] data; 

} packet_t; 




5.3.12 Passing argument values by reference instead of copy 



values are 
passed in and 
out of tasks and 
functions by 
copy 



When a task or function is called, inputs are copied into the task or 
function. These values then become local values within the task or 
function. When the task or function returns at the end of its execu- 
tion, all outputs are copied out to the caller of the task or function. 



SystemVerilog extends tasks and functions by adding the capability 
to pass values by reference instead of by copy. Passing by reference 
allows a variable to be declared in just the calling scope, and not 
duplicated within a task or function. Instead, the task or function 
refers to the variable in the scope from which it is called. 
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To pass a value by reference, the formal argument is declared using 
the keyword ref instead of the direction keywords input, output 
or inout. The name of the ref argument becomes an alias of the 
hierarchical reference to the actual storage for the value passed to 
the task or function. The actual declaration and storage of the value 
is declared in the scope that calls the task or function. 

In the example below, a structure called data_packet and an 
array called raw_data are allocated in module chip. These 
objects are then passed as arguments in a call to the f ill_packet 
function. Within f ill_packet, the formal arguments are declared 
as ref arguments, instead of inputs and outputs. The formal argu- 
ment data_in becomes an alias within the task for the raw_data 
array in the calling scope, chip. The formal argument data_out 
becomes an alias for the data ^packet structure within chip. 

module chip (...); 

typedef struct packed { 

bit valid; 

bit [ 7:0] check; 

bit [63:0] data; 

} packet_t; 

packet_t data_j?acket ; 

bit [7:0] raw__data [0:7] ; 

always @(posedge clock) 

fill_packet ( .data_in (raw_data) , 

.data_out (data_packet) ); 

task fill_packet ( 

ref bit [7:0] data_in [0:7], // ref arg 
ref packet_t data_out ) ; // ref arg 

for (int i=0 ; i<=7; i++) begin 

data_out.data[(8*i)+:8] = data_in[i]; 
data_out. check [i] = A data_in[i]; 

end 

data-out .valid = 1; 

endtask 

endmodule 



a ref formal 
arguments is an 
alias to the 
actual value 
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Read-only reference arguments 

pass by A reference formal argument can be declared to only allow reading 
reference can 0 f the object that is referenced, by declaring the formal argument as 
be readonly congt ref This can be used to allow the task or function to refer- 
ence the information in the calling scope, but prohibit the task or 
function from modifying the information within the calling scope. 

task fill_packet ( 

const ref bit [7:0] data_in [0:7], 
ref packet_t data__out ) ; 

endtask 

Ref arguments are sensitive to changes in calling scope 

pass by An important characteristic of ref arguments is that the logic of the 
reference allows task can be sensitive to when the signal in the calling scope changes 
sensitivity to va j ue j n the following example, the received packet and done 
** flag are passed by reference. This allows the wait statement to 
observe when the flag becomes true in the module that calls the 
task. If done had been copied in as an input, the wait statement 
would be looking at the local copy of done, which would not be 
updated when the done flag changed in the calling module. 

typedef struct packed { 

bit valid; 

bit [ 7:0] check; 

bit [63:0] data; 

} packet _t ; 

packet_t sendjpacket, receive_packet ; 

task automatic check_results ( 
input packet_t sent, 
ref packet__t received, 
ref done ) ; 

static int error_count = 0; 
wait (done) 

if (sent !== received) begin 
error_count++; 

$display( "ERROR! received bad packet"); 

end 

endtask 
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Ref arguments can read current values 

In the preceding example, the sent packet is an input, which is 
copied in at the time the task is called. The received packet is 
passed by reference, instead of by copy. When the done flag 
changes, the task will compare the current value of the received 
packet with the copy of the sent packet from the time when the 
task was called. If the received packet had been copied in, the 
comparison would have been made using the value of the 
received packet at the time the task was called, instead of at the 
time the done flag became true. 

Ref arguments can propagate changes immediately 

When task outputs are passed by copy, the value is not copied back 
to the calling scope until the task exits. If there are time controls or 
event controls between when the local copy of the task argument is 
changed and when the task exits, the calling scope will see the 
change to the variable when the task exits, and not when the local 
copy inside the task is assigned. 

When a task output is passed by reference, the task is making its 
assignment directly to the variable in the calling scope. Any event 
controls in the calling scope that are sensitive to changes on the 
variable will see the change immediately, instead of waiting until 
the task completes its execution and output arguments are copied 
back to the calling scope. 

Restrictions on calling functions with ref arguments 

A function with ref formal arguments can modify values outside 
the scope of the function, and therefore has the same restrictions as 
functions with output arguments. A function with output, inout 
or ref arguments can not be called from: 

• an event expression 

• an expression within a procedural continuous assignment 

• an expression that is not within a procedural statement 

These restrictions do not apply to a const ref function argument, 
as this type of formal argument is read-only, and cannot modify a 
value outside of the function. 
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5.3.13 Named task and function ends 

SystemVerilog allows a name to be specified with the endtask or 
endfunction keyword. The syntax is: 

endtask : <task_name> 
endfunction : <function_name> 

The white space before and after the colon is optional. The name 
specified must the same as name of the corresponding task or func- 
tion. For example: 

function int add_and__inc (int a, b) ; 
add_and__inc = a + b; 
return ++add__and_inc; 
endfunction : add and inc 



task automatic check_results ( 
input packet_t sent, 
ref packet_t received, 
ref done ) ; 

static int error_count = 0; 
endtask: check__results 

Specifying a name with the endtask or endfunction keyword 
can help make large blocks of code easier to read, thus making the 
model more maintainable. 

5.3.14 Empty tasks and functions 

a task or Verilog requires that tasks and functions contain at least one state- 
function can be me nt (which can be an empty begin.. .end statement group). Sys- 
empty temVerilog allows tasks and functions to be completely empty, 
with no statements or statement groups at all. An empty function 
will return the current value of the implicit variable that represents 
the name of the function. 

An empty task or function is a place holder for partially completed 
code. In a top-down design flow, creating an empty task or function 
can serve as documentation in an abstract model for the place 
where more detailed functionality will be filled in later in the 
design flow. 
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5.4 Summary 



This chapter has presented the always_comb, alwayslatch, 
and always_f f specialized procedural blocks that SystemVerilog 
adds to the Verilog standard. These specialized procedural blocks 
add semantics that increase the accuracy and portability for model- 
ing hardware, particularly at the synthesizable RTL level of model- 
ing. Also important is that these specialized procedural blocks 
make the designer’s intent clear as to what type of logic the proce- 
dural block should represent. Software tools can then examine the 
contents of the procedural block, and issue warnings if the code 
within the procedural block cannot be properly realized with the 
intended type of hardware. 

SystemVerilog also adds a number of enhancements to Verilog 
tasks and functions. These enhancements include simplifications of 
Verilog syntax or semantic rules, as well as new capabilities for 
how tasks and functions can be used. Both types of changes allow 
modeling larger and more complex designs more quickly and with 
less coding. 




Chapter 6 

SystemVerilog 
Procedural Statements 



OystemVerilog adds several new operators and procedural state- 
O ments to the Verilog language that allow modeling at a more 
abstract, C-like level. Additional enhancements convey the 
designer’s intent, helping to ensure that all software tools interpret 
the procedural statements in the same way. This chapter covers 
these operators and procedural statements, and offers guidelines on 
how to properly use these new constructs. 

This SystemVerilog features presented in this chapter include: 

• New operators 

• Enhanced for loop 

• New bottom testing loop 

• New jump statements 

• Enhanced block names 

• Statement labels 

• Unique and priority decisions 
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6.1 New operators 



6.1.1 Increment and decrement operators 

++am/~ SystemVerilog adds the ++ increment operator and the -- decre- 
operators m ent operator to the Verilog language. These operators are used in 
the same way as in C. For example: 

for (i = 0; i <= 31; i++ ) 

@(posedge shif t_clock) serial__out <= data[i]; 

Post-increment and pre-increment 

As in C, the increment and decrement operators can be used to 
either pre-increment/pre-decrement a variable, or to post-incre- 
ment/post-decrement a variable. Table 6-1 shows the four ways in 
which the increment and decrement operators can be used. 



Table 6-1: Increment and decrement operations 



Statement 


Operation 


Description 


j = i++; 


post-increment 


j is assigned the value of i, and then i is incremented by 1 


itma 


pre-increment 


i is incremented by 1, and j is assigned the value of i 


j « i--; 


post-decrement 


j is assigned the value of i, and then i is decremented by 1 


j = --i; 


pre-decrement 


i is decremented by 1, and j is assigned the value of i 



The following code fragments show how pre-increment versus post 
increment can affect the termination value of a loop. 

while (i++ < LIMIT) begin: loopl 

... // last value of i will be LIMIT 

end 

while (++j < LIMIT) begin: loop2 

... // last value of j will be LIMIT- 1 

end 

In loopl, the current value of i will first be compared to LIMIT, 
and then i will be incremented. Therefore, the last value of i within 
the loop will be equal to limit. 
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In loop2, the current value of j will first be incremented, and then 
the new value compared to limit. Therefore, the last value of j 
within the loop will be one less than limit. 



Avoiding race conditions 



The Verilog language has two assignments operators, blocking and 
nonblocking. The blocking assignment is represented with a single 
equal token ( » ), and the nonblocking assignment is represented 
with a less-than-equal token ( <* ). 

out = in; // blocking assignment 
out <= in; // nonblocking assignment 

blocking and A full explanation of blocking and nonblocking assignments is 
nonblocking beyond the scope of this book. A number of books on the Verilog 
assignments language discuss the behavior of these constructs. The primary pur- 
pose of these two assignment operators is to accurately emulate the 
behavior of combinational and sequential logic in zero delay mod- 
els. Proper usage of these two types of assignments is critical, in 
order to prevent simulation event race conditions. A general guide- 
line is to use blocking assignments to model combinational logic, 
and nonblocking assignments to model sequential logic. 



The ++ and -- operators behave as blocking assignments. 

++ and - The increment and decrement operators behave as blocking assign- 

behave as ments. The following two statements are semantically equivalent: 
blocking 

assignments i++ ; // increment i with blocking assign 

i = i + 1; // increment i with blocking assign 




++ and - can 
have race 
conditions in 
sequential logic 



Just as it is possible to misuse the Verilog blocking assignment, cre- 
ating a race condition within simulation, it is also possible to mis- 
use the increment and decrement operators. The following example 
illustrates how an increment or decrement operator could be used in 
a manner that would create a simulation race condition. In this 
example, a simple counter is incremented using the ++ operator. 
The counter, which would be implemented as sequential logic using 
some form of flip-flops, is modeled using a sequential logic 
always f f procedural block. Another sequential logic procedural 
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block reads the current value of the counter, and performs some 
type of functionality based on the value of the counter. 

always__ff @(posedge clock) 
if (IresetN) count <= 0; 

else count++; // same as count = count + 1; 

always_ff ©(posedge clock) 
case (state) 

HOLD: if (count == MAX) 



Will count in this example be read by the second procedural block 
before or after count is incremented? This example has two proce- 
dural blocks that trigger at the same time, on the positive edge of 
clock. This creates a race condition, between the procedural block 
that increments count and the procedural block that reads the value 
of count. The defined behavior of a blocking assignment is that the 
software tool can execute the code above in either order. This 
means a concurrent process can read the value of a variable that is 
incremented with the ++ operator (or decremented with the -- 
operator) before or after the variable has changed. 

The pre-increment and pre-decrement operations will not resolve 
this race condition between two concurrent statements. Pre- and 
post- increment/decrement operations affect what order a variable 
is read and changed within the same statement. They do not affect 
the order of reading and changing between concurrent statements. 

A nonblocking assignment is required to resolve the race condition 
in the preceding example. The behavior of a nonblocking assign- 
ment is that all concurrent processes will read the value of a vari- 
able before the assignment updates the value of the variable. This 
properly models the behavior of a transition propagating through 
sequential logic, such as the counter in this example. 



PT^P Avoid using ++ and -- on variables where nonblocking 
assignment behavior is required. 



guidelines for To prevent potential race conditions, the increment and decrement 
using ++ and- operators should only be used to model combinational logic. 

Sequential and latched logic procedural blocks should not use the 
increment and decrement operators to modify any variables that are 
to be read outside of the procedural block. Temporary variables that 




Chapter 6: SystemVerilog Procedural Statements 



137 



are only read within a sequential or latched logic procedural block 
can use the ++ and - - operators without race conditions. For exam- 
ple, a variable used to control a for loop can use the ++ or - - oper- 
ators even within a sequential procedural block, so long as the 
variable is not read anywhere outside of the procedural block. 

The proper way to model the preceding example is shown below. 
The ++ operator is not used, because count is representing the out- 
put of sequential logic that is to be read by another concurrent pro- 
cedural block. 

always^ ff @(posedge clock) 
if (IresetN) count <= 0; 

else count <= count +1; // nonblocking assign 

always_ff @(posedge clock) 
case (state) 

HOLD: if (count == MAX) 



Synthesis guidelines 

Both the pre- and post- forms of the increment and decrement oper- 
ators are synthesizable, but only when used as a separate statement. 

i++; // synthesizable 

sum = i++; // not synthesizable 

6.1.2 Assignment operators 

+= and other SystemVerilog adds several additional types of assignment opera- 
assignment tors to Verilog. These new operators combine some type of opera- 
operators t j on w j t j 1 flj e assignment. 

All of the new assignment operators have the same general syntax. 
For example, the +■ operator is used as: 

out += in; // add and assign 

The += operator is a short cut for the statement: 

out = out + in; // add and assign 

Table 6-2 lists the assignment operators which SystemVerilog adds 
to the Verilog language. 
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Table 6-2: SystemVerilog assignment operators 



Operator 


Description 


■i 


add right-hand side to left-hand side and assign 


— 


subtract right-hand side from left-hand side and assign 


* = 


multiply left-hand side by right-hand side and assign 


/= 


divide left-hand side by right-hand side and assign 


%- 


divide left-hand side by right-hand side and assign the remainder 


& = 


bitwise AND right-hand side with left-hand side and assign 


h 


bitwise OR right-hand side with left-hand side and assign 


A 


bitwise exclusive OR right-hand side with left-hand side and assign 


<< = 


bitwise left-shift the left-hand side by the number of times indicated by the 
right-hand side and assign 


>>5= 


bitwise right-shift the left-hand side by the number of times indicated by the 
right-hand side and assign 


m 


arithmetic left-shift the left-hand side by the number of times indicated by the 
right-hand side and assign 


>>>= 


arithmetic right-shift the left-hand side by the number of times indicated by 
the right-hand side and assign 




Assignment operators behave as blocking assignments. 



assignment 
operators are 
blocking 
assignments 



The assignment operators have a blocking assignment behavior. To 
avoid simulation race conditions, the same care needs to be taken 
with these assignment operators as with the ++ and -- increment 
and decrement operators, as described in section 6. 1 . 1 on page 134. 



Synthesis guidelines 

The assignment operators are synthesizable, but synthesis compil- 
ers may place restrictions on multiply and divide operations. 



Example 6-1 illustrates using the SystemVerilog assignment opera- 
tors. The operators are used in a combinational logic procedural 
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block, which is the correct type of procedural block for blocking 
assignment behavior. 

Example 6-1 : Using SystemVerilog assignment operators 

typedef enusi {ADD, SUB, MULT, DIV, SL, SR} opcode_t; 

typedef enum {UNSIGNED, SIGNED} operand_type_t ; 

typedef union packed { 

logic [23:0] u_data; 

bit signed [23:0] s_data; 

} data_t; 

typedef struct packed { 

opcode_t opc ; 

operand_type_t op__type ; 
data_t op_a; 

data_t op_b ; 

} instruction^ ; 

module alu (input instruction^ instr, output data_t alu_out) ; 
always_comb begin 

if (instr .op_type == SIGNED) begin 
alu_out . s_data = instr .op__a . s_data; 
case (instr. opc) 

ADD : alu_out . s__data += instr .op_b. s_data; 

SUB : alu__out . s_data -= instr . op_b. s_data; 

MULT : alu_out . s__data *= instr . op_b. s__data; 

DIV : alu_out . s_data /= instr .op_b. s_data; 

SL : alu_out . s_data <<<= 2; 

SR : alu_out . s_data >>>= 2; 

endcase 
end 

else begin 

alu__out . u_data = instr . op_a . u_data ; 
case ( instr . opc ) 

ADD : alu_out .u_data += instr .op_b.u_data; 

SUB : alu_out .u_data - = instr . op_b.u__data; 

MULT : alu_out . u_data *= instr .op_b.u_data; 

DIV : alu_out .u_data /= instr .op_b.u__data; 

SL : alu_out .u_data <<= 2; 

SR : alujout .u_data >>= 2; 

endcase 
end 
end 

endmodule 
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6.1.3 Equality operators with don’t care wild cards 

The Verilog language has two types of equality operators, the == 
operator and the === operator (referred to as the case equality oper- 
ator or as the identity operator). Both operators compare two 
expressions, and return true if the expressions are the same, and 
false if they are different. The two operators handle logic X and 
logic Z values differently: 

• The == operator will consider any comparison where X or Z val- 
ues are in either operand to be unknown, and return a logic X. 

• The === case equality operator will perform a bit-wise compari- 
son of the two operands, and look for an exact match of 0, 1, X 
and Z values in both operands. If the operands are identical, the 
operator will return true, otherwise, the operator will return false. 

Each of these operators has a not-equal counterpart, l = and I ==. 
These operators invert the results of the true/false test, returning 
true if the operands are not equal, and false if they are equal. 

SystemVerilog provides two additional case equality operators, 
*?« and !?«. These operators allow for don’t-care bits to be 
masked from the comparison. The =?= operator, referred to as the 
wild equality operator , will perform a bit-wise comparison of its 
two operands, similar to the = case equality operator. With the 
=?= wild equality operator, however, a logic X or a logic Z in a bit 
position of either operand is treated as a wildcard that will match 
any value in the corresponding bit position of the other operand. 

Table 6-3 shows the differences in the types of equality operators. 



Table 6-3: SystemVerilog equality operators 



a 


b 


a = b 


a = b 


a*? b 


a != b 


a !== b 


a !?= b 


0000 


0000 


true 


true 


true 


false 


false 


false 


0000 


0101 


false 


false 


false 


true 


true 


true 


010Z 


0101 


unknown 


false 


true 


unknown 


true 


false 


010Z 


010Z 


unknown 


true 


true 


unknown 


false 


false 


010X 


010Z 


unknown 


false 


true 


unknown 


true 


false 


010X 


010X 


unknown 


true 


true 


unknown 


false 


false 
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The wild equality operators allow performing a decision based on 
the value of a vector, with specific bits of the vector masked out. 
The bits which are masked out are treated as don’t care bits, and 
have no bearing on the result of the outcome of a true/false test. 

bit [7:0] opcode; 

if (opcode =?= 8'bll011???) // mask out low bits 



If the operands are not the same size, then the wild equality opera- 
tors will expand the vectors to the same size before performing the 
comparison. The vector expansion rules are the same as with the 
case equality operators. 

Synthesis guidelines 

Currently, the wild equality operators are not synthesizable. These 
operators should be reserved for use in verification testbenches and 
abstract behavioral models that will not be synthesized. 

6.1.4 Set membership operator — inside 

SystemVerilog adds an operator to test if a value matches anywhere 
within a set of values. The operator uses the keyword, inside. 

bit [2:0] a; 

if ( a inside {3'b001, 3'b010, 3'bl00} ) 



The inside operator can simplify comparing a value to several 
possibilities. Without the inside operator, the preceding if decision 
would likely have been coded as: 

if ( (a==3 ' bOOl) || (a==3'b010) || (a==3'b!00} ) 



The set of values to which the first value is matched can be other 
signals. 

if ( data inside {busl, bus2, bus3, bus4} ) 
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The set of values can also be an array. The next example tests to see 
if the value of 13 occurs anywhere in an array called d_array. 

int d_array [0:1023]; 
if ( 13 inside d_array) 



The inside operator uses the value Z to represent don’t care con- 
ditions. The following test will be true if a has a value of 3 ' blOl, 
3'blll, 3'blxl, or 3'blzl. 

logic [2:0] a; 

if (a inside {3'bl?l}) 



This is similar to the cases statement, but with an important differ- 
ence. The cases statement treats Z values on both sides of the 
comparison as don’t care bits. The inside operator only treats Z 
values in the set of expressions as don’t care bits. Bits in the first 
operand, the one before the inside keyword, are not treated as 
don’t care bits. 

Synthesis guidelines 

The inside operator is synthesizable. When don’t care expres- 
sions are used, synthesis compilers may require that the expressions 
in the value set (on the right-hand side of the inside operator) be lit- 
eral values. 



6.2 Operand enhancements 



6.2.1 Operations on 2-state and 4-state types 

Verilog defines the rules for operations on a mix of most data types. 
SystemVerilog extends these rules to also cover operations on 2- 
state types, which Verilog does not have. 

operations with For operations that involve two operands: 
all 2-state types 

have 2-state • When both operands are 2-state data types, such as bit or int, 
results resu it will be 2-state. 
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• When both operands are 4-state data types, such as logic, reg 
or integer, the result will be 4-state. 

• When one operand is 2-state and the other operand is 4-state, the 
result will be 4-state. 

For unary reduction operators: 

• If the operand type is 4-state, the result will be of type logic 

• If the operand type is 2-state, the result will be of type bit 

For the increment and decrement operators, the result will be the 
same data type as the operand. 

The assignment operators will follow the same rules as the equiva- 
lent operator that uses two operands. If any operand is 4-state, then 
the result will be 4-state. 

Operations involving the new shortreal data type follow the 
same rules and have the same restrictions as the Verilog real data 
type. 



6.2.2 Casting expression sizes 

In Verilog, the number of bits of an expression is determined by the 
operand, the operation, and the context. The IEEE 1364-2001 Ver- 
ilog standard defines the rules for determining the size of an expres- 
sion. SystemVerilog follows the same rules as defined in Verilog. 



vector widths SystemVerilog extends Verilog by allowing the size of an expres- 
can be cast to a s ion to be cast to a different size. An explicit cast can be used to set 
different size s j ze 0 f an operand, or to set the size of an operation result. 



bit [15:0] a, b, c, sum; // 16 bits wide 
bit carry; // 1 bit wide 



sum = a + 16' (5) ; 

{carry, sum} = 17' (a + 3) ; 
sum = a + 16' (b - 2) / c; 



// cast operand 

// cast result 

// cast intermediate 
// result 
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If an expression is cast to a smaller size than the number of bits in 
the expression, the left-most bits of the expression are truncated. If 
the expression is cast to a larger vector size, then the expression is 
left-extended. These are the same rules as when an expression of 
one size is assigned to a variable or net of a different size. 

6.2.3 Casting expression signedness 

SystemVerilog follows Verilog rules for determining if an opera- 
tion result is signed or unsigned. The new ++ and - - increment and 
decrement operators follow the rules for unary operations, where 
the result of the operation has the same signedness as the operand. 

SystemVerilog also allows explicitly casting the signedness of a 
value. Either the signedness of an operand can be cast, or the sign- 
edness of an operation result can be cast. 

sum = signed' (a) + signed' (a) ; // cast operands 

if (unsigned 1 (a-b) <= 5) // cast intermediate 

... // result 

The SystemVerilog cast operators, when used to cast the signedness 
of a value, perform the same conversion as the Verilog $signed 
and $unsigned system functions. Sign casting is synthesizable, 
following the same rules as the $ signed and $unsigned system 
functions. 



6.3 Enhanced for loops 



Verilog for loop In Verilog, the variable used to control a for loop must be declared 
variables are prior to the loop. When multiple for loops are used, separate vari- 
dedared outside a bi es must b e declared for each loop: 



module chip (...); // Verilog style loops 

reg [7:0] i; 
integer j , k ; 



always @(posedge clock) begin 
for (i * 0; i <= 15; i = i + 1) 

for (j a 511; j >= 0; j = j - 1) begin 



end 



end 
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always @(posedge clock) begin 

for (k = 1; k <= 1024; k = k + 2) begin 

end 

end 

endmodule 

concurrent loops Because the variable must be declared outside of the for loop, cau- 
can interfere tion must be observed when concurrent procedural blocks within a 
with each other mo( j u i e have for loops. If the same variable is inadvertently used 
as a loop control in two or more concurrent loops, then each loop 
will be modifying the control variable used by another loop. Either 
different variables must be declared at the module level, as in the 
example above, or local variables must be declared within each 
concurrent procedural block, as shown in the following example. 

module chip (...); // Verilog style loops 

always @(posedge clock) begin: loopl 
reg [7:0] i; // local variable 
for (i = 0; i <= 15; i = i + 1) begin 

end 

end 

always @(posedge clock) begin: loop2 
integer i; // local variable 
for (i = 1; i <= 1024; i = i + i) begin 

end 

end 

endmodule 



6.3.1 Local variables within for loop declarations 

declaring local SystemVerilog simplifies declaring local variables for use in for 
loop variables loops. With SystemVerilog, the declaration of the for loop vari- 
able can be made within the for loop itself. This eliminates the 
need to define several variables at the module level, or to define 
local variables within named begin.. .end blocks. 

module chip (...); // SystemVerilog style loops 

always__ff ©(posedge clock) begin 
for (bit [4:0] i = 0; i <= 15; i++) 
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local loop 
variables 
prevent 
interference 



local loop 
variables are 
automatic 



local loop 
variables do not 
exist outside of 
the loop 



end 

always_ff @(posedge clock) begin 
for (int i = 1; i <= 1024; i += 1) 

end 

endmodule 

A variable declared within as part of a for loop is local to the loop. 
References to the variable name within the loop will see the local 
variable, and not any other variable of the same name elsewhere in 
the containing module, interface, program, task, or function. 



Variables declared as part of a for loop are automatic variables. 

When a variable is declared as part of a for loop initialization 
statement, the variable has automatic storage, not static storage. 
The variable is created and initialized when the for loop is 
invoked, and destroyed when the loop exits. The use of automatic 
variables has important implications: 

• Automatic variables cannot be referenced hierarchically. 

• Automatic variables cannot be dumped to VCD files. 

• The value of the for loop variable cannot be used outside of the 
for loop, because the variable does not exist outside of the loop. 




The following example is illegal. The intent is to use a for loop to 
find the lowest bit that is set within a 64 bit vector. Because the 
lojait variable is declared as part of the for loop, however, it is 
only in existence while the loop is running. When the loop termi- 
nates, the variable disappears, and cannot be used after the loop. 

always_comb begin 

for (int lo__bit=0 ; lo_bit<=63; lo_bit++) begin 
if (data [lo__bit] ) break; // exit loop if 
end // bit is set 

if (lo_bit >7) // ERROR: lo_bit is not there 



end 



When a variable needs to be referenced outside of a loop, the vari- 
able must be declared outside of the loop. For example: 
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always^cosib begin 

int lo__bit; // local variable to the block 
for (lo__bit=0; lo_bit<=63; lo_bit++) begin 
if (data [lo_bit] ) break; // exit loop if 
end // bit is set 

if (lo_bit >7) // lo_bit has last loop value 

end 



6.3.2 Multiple for loop assignments 

SystemVerilog also enhances Verilog for loops by allowing more 
than one initial assignment statement, and more than one step 
assignment statement. Multiple initial or step assignments are sepa- 
rated by commas. For example: 

for (int i=l, int j=0; i*j < 128; i++, j+=3) 



6.3.3 Hierarchically referencing variables declared in for loops 

local loop Local variables declared as part of a for loop cannot be referenced 
variables do not hierarchically. A testbench, waveform display, or a VCD file can- 

have a hierarchy not re f ere nce the local variable. 
path 

always_ff @(posedge clock) begin 

for (int i = 0; i <= 15; i++) begin 

...// i cannot be referenced hierarchically 

end 

end 

When hierarchical references to a for loop control variable is 
required, the variable should be declared outside of the for loop, 
either at the module level, or in a named begin... end block. 

always_ff @(posedge clock) begin : loop 

int i; // i can be referenced hierarchically 
for (i = 0; i <= 15; i++) begin 

end 

end 

In this example, the variable i can be referenced hierarchically with 
the last portion of the hierarchy path ending with . loop . i . 
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6.3.4 Synthesis guidelines 

SystemVerilog’s enhanced for loops are synthesizable, following 
the same synthesis coding guidelines as Verilog for loops. 



6.4 Bottom testing do...while loop 



Verilog has the while loop, which executes the loop as long as a 
loop-control test is true. The control value is tested at the beginning 
of each pass through the loop. 

a while loop It is possible that a while loop might not execute at all. This will 
might not occur if the test of the control value is false the very first time the 
execute at all j 00 p j s encountered in the execution flow. 

This top-testing behavior of the while loop can require extra code 
prior to the loop, in order to ensure that any output variables of the 
loop are consistent with variables that would have been read by the 
loop. In the following example, the while loop executes as long as 
an input address is within the range of 128 to 255. If, however, the 
address is not in this range, the while loop will not execute at all. 
Therefore, the range has to be checked prior to the loop, and the 
three loop outputs, done, OutOfBound, and out set for out-of- 
bounds address conditions. 

always_comb begin 

if (addr < 128 | | addr > 255) begin 
done = 0; 

OutOfBound = 1; 
out = mem [128] ; 

end 

else while (addr >= 128 && addr <= 255) begin 
if (addr == 128) begin 
done = 1; 

OutOfBound = 0; 

end 

else begin 

done a= 0; 

OutOfBound = 0; 

end 

out = mem [addr] ; 
addr -= 1 ; 

end 

end 
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a do... while loop SystemVerilog adds a do.. .while loop, as in C. With the 
will execute at do., .while loop, the control for the loop is tested at the end of each 
least once p ass 0 f j 00 p ? instead of the beginning. This means that each 
time the loop is encountered in the execution flow of a procedural 
block, the loop statements will be executed at least once. 

The basic syntax of a do.. .while loop is: 

do <statement or statement block> 
while (<condition>) ; 

If the do portion of the loop contains more than one statement, the 
statements must be grouped in a begin... end block. The while 
statement comes after the block of statements to be executed. Note 
that there is a semicolon after the while statement. 

Because the statements within a do.. .while loop are guaranteed to 
execute at least once, all the logic for setting the outputs of the loop 
can be placed inside the loop. This bottom-testing behavior can 
simplify the coding of while loops, making the code more concise 
and more intuitive. 

In the next example, the do.. .while loop will execute at least once, 
thereby ensuring that the done, OutOfBound, and out variables 
are consistent with the inputs to the loop. No additional logic is 
required before the start of the loop. 

always_comb begin 
do begin 

done = 0; 

OutOfBound = 0; 
out = mem[addr]; 

if (addr <128 | | addr > 255) begin 
OutOfBound = 1; 
out = mem [128] ; 

end 

else if (addr == 128) done = 1; 
addr -= 1; 

end 

while (addr >= 128 && addr <= 255) ; 

end 
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6.4.1 Synthesis guidelines 

Verilog while loops are generally synthesizable, with a number of 
restrictions. These same restrictions apply to SystemVerilog’s 
do.. .while loop. The restrictions allow synthesis compilers to stat- 
ically determine how many times a loop will execute. Without 
restrictions, the while loop and do... while loops can execute an 
arbitrary number of times, until some expression evaluates as false. 
Executing an arbitrary number of times requires run-time dynamics 
that are not available to synthesis compilers. 



6.5 New jump statements — break, continue, return 

Verilog uses the disable statement as a way to cause the execu- 
tion flow of a sequence of statements to jump to a different point in 
the execution flow. Specifically, the disable statement causes the 
execution flow to jump to the end of a named statement group, or to 
the end of a task. 

The disable statement can be used a variety of ways. It can be 
used to jump to the end of a loop, and continue execution with the 
next pass of the loop. The same disable statement can also be 
used to prematurely break out of all passes of a loop. The multiple 
usage of the same keyword can make it difficult to. read and main- 
tain complex blocks of code. Two ways of using disable are illus- 
trated in the next example. The effect of the disable statement is 
determined by the placement of the named blocks being disabled. 

// find first bit set within a range of bits 

always @* begin 
begin : loop 
integer i; 
first__bit = 0; 

for (i=0; i<=63; i=i+l) begin: pass 
if (i < start_range) 

disable pass; // continue loop 
if (i > end__range) 

disable loop; // break out of loop 
if ( data[i] ) begin 
first _bit * i; 

disable loop; // break out of loop 

end 

end // end of one pass of loop 
end // end of the loop 



the disable 
statement is 
both a continue 
and a break 
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... // process data based on first bit set 

end 

the disable The disable statement can also be used to return early from a 

statement can task, before all statements in the task have been executed. 
be used as a 

return task add_to_max (input [ 5:0] max, 

output [63:0] result); 

integer i; 
begin 

result = 1; 
if (max == 0) 

disable add_to_max; // exit task 
for (i=l; i<=63 ; i=i+l) begin 
result = result + result; 
if (i == max) 

disable add__to__max; // exit task 

end 

end 

endtask 

The disable statement can also be used to externally disable a 
concurrent process or task. An external disable is not synthesizable, 
however. 

continue, break SystemVerilog adds the C language jump statements: break, con- 
and return tinue and return. These jump statements can make code more 
statements j n tuitive and concise. SystemVerilog does not include the C goto 
statement. 

An important difference between Verilog’s disable statement and 
these new jump statements is that the disable statement applies to 
all currently running invocations of a task or block, whereas break, 
continue and return only apply to the current execution flow. 

6.5.1 The continue statement 

The continue statement jumps to the end of the loop and executes 
the loop control, if present, like a continue statement in C. Using 
the continue statement, it is not necessary to add named 
begin.. .end blocks to the code, as is required by the disable 
statement. 



bit [15:0] array [0:255]; 
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always_comb begin 

for (int i = 0; i <= 255; i++) begin : loop 
if (array [i] == 0) 

continue; // skip empty elements 
transform_f unction (array [i] ) ; 
end // end of loop 
end 



6.5.2 The break statement 

The break statement terminates the execution of a loop immedi- 
ately. The loop is not executed again unless the execution flow of 
the procedural block encounters the beginning of the loop again, as 
a new statement. 

// find first bit set within a range of bits 
always_coxnb begin 
first_bit = 0; 

for (int i=0; i<=63; i=i+l) begin 
if (i < start_range) continue; 
if (i > end_jrange) break; // exit loop 
if ( data[i] ) begin 
first_bit = i; 
break; // exit loop 
end 

end // end of the loop 

... // process data based on first bit set 

end 

The SystemVerilog break statement is used in the same way as a 
break in C to break out of a loop. C also uses the break statement 
to exit from a switch statement. SystemVerilog does not use 
break to exit a Verilog case statement (analogous to a C switch 
statement). A case statement exits automatically after a branch is 
executed, without needing to execute a break. 

6.5.3 The return statement 

SystemVerilog adds a C-like return statement, which is used to 
return a value from a non-void function, or to return from a void 
function or a task. The return statement can be executed at any 
time in the execution flow of the task or function. When the 
return is executed, the task or function exits immediately, without 
needing to reach the end of the task or function. 
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task add__to_max (input [ 5:0] max, 

output [63:0] result); 

result = 1; 

if (max == 0) return; // exit task 
for (int i=l; i<=63; i=i+l) begin 
result = result + result; 
if (i == max) return; // exit task 

end 

endtask 

The return statement can be used to exit early from either a task 
or a function. The Verilog disable statement can only cause a task 
to exit early. It cannot be used with functions. 

function automatic int log2 (input int n) ; 
if (n <=1) return 1; 
log2 = 0; 

while (n > 1) begin 
n = n/2; 
log2++; 

end 

return log2; 
end function 

Note that the return keyword must not be followed by an expres- 
sion in a task or void function, and must be followed by an expres- 
sion in a non-void function. 

6.5.4 Synthesis guidelines 

The break, continue, and return jump statements are synthe- 
sizable constructs. The synthesis results are the same as if a Verilog 
disable statement had been used to model the same functionality. 



6.6 Enhanced block names 



Complex code will often have several nested begin.. .end state- 
ment blocks. In such code, it can be difficult to recognize which 
end is associated with which begin. 
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code can have The following example illustrates how a single procedural block 
several nested might contain several nested begin... end blocks. Even with proper 
blocks * nc * ent * n S anc * keyword bolding as used in this short example, it can 
be difficult to see which end belongs with which begin. 

Example 6-2: Code snippet with unnamed nested begin.. .end blocks 

always_£f ©(posedge clock, posedge reset) 
begin 

bit breakVar; 
if (reset) begin 

... // reset all outputs 

end 

else begin 

case (SquatState) 
wa i t_r x_va lid: 
begin 

Rxready <= '1; 
breakVar = 1; 

for (int j = 0 ; j<NumRx; j+=l) begin 
for (int i=0; i<NumRx; i+=l) begin 

if (Rxvalid[i] && RoundRobin [i] && breakVar) 

begin 

ATMcell <= RxATMcell [i] / 

Rxready [i] <= 0; 

SquatState <= wait_rx__not_valid; 
breakVar = 0; 

end 

end 

end 

end 

... // process other SquatState states 

endcase 

end 

end 



named ends can Verilog allows a statement block to have a name, by appending 
be paired with . < n ame> after the begin keyword. The block name creates a local 
named begins hierarchy scope that serves to identify all statements within the 
block. SystemVerilog allows (but does not require) a matching 
block name after the end keyword. This additional name does not 
affect the block semantics in any way, but does serve to enhance 
code readability by documenting which statement group is being 
completed. 
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To specify a name to the end of a block, a : <name> is appended 
after the end keyword. White space is allowed, but not required, 
before and after the colon. 

begin: <block__name> 

end: <block_name> 

The optional block name that follows an end must match exactly 
the name with the corresponding begin. It is an error for the corre- 
sponding names to be different. 

The following code snippet modifies example 6-2 on the previous 
page by adding names to the begin... end statement groups, help- 
ing to make the code easier to read. 

Example 6-3: Code snippet with named begin and named end blocks 

always__ff @(posedge clock, posedge reset) 
begin : FSM_j?rocedure 
bit breakVar; 

if (reset) begin: reset__logic 
... // reset all outputs 
end: reset_logic 
else begin: FSM_sequencer 
unique case (SquatState) 
wa i t _rx_va lid: 

begin: rx_valid_state 
Rxready <= 1 1 ; 
breakVar = 1; 

for (int j = 0 ; j<NumRx; j+=l) begin: loopl 
for (int i=0; i<NumRx; i+=l) begin: loop2 
if (Rxvalidfi] && RoundRobin [i] && breakVar) 
begin: match 

ATMcell <= RxATMcell [i] ; 

Rxready [i] <= 0; 

SquatState <= wait_rx__not_valid; 
breakVar = 0; 
end: match 
end : loop2 
end: loopl 
end: rx_valid_j3tate 
... // process other SquatState states 
endcase 

end: FSM_sequencer 
end : FSM_procedure 
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6.7 Statement labels 



a named block In addition to named blocks of statements, SystemVerilog allows a 

identifies a label to be specified before any procedural statement. Statement 

group of i a 5 e i s use the same syntax as C: 
statements 



<label> : <statement> 

a statement A statement label is used to identify a single statement, whereas a 

label identifies a named statement block identifies a block of one of more statements. 
single statement 

always_comb begin : decode_block 
decoder : case (opcode) 

2 ' bOO : 

outer_loop: for (int i=0; i<=15; i++) 
inner__loop: for (int j=0; j<=15; j++) 

//... 

... // decode other opcode values 

endcase 

end : decode_block 

a labeled Statement labels document specific lines of code, which can help 

statement make the code more readable, and can make it easier to reference 

creates a name those lines of code in other documentation. Statement labels can 
scone 

H also be useful to identify specific lines of code for debug utilities 
and code coverage analysis tools. Statement labels also allow state- 
ments to be referenced by name. A statement that is in the process 
of execution can be aborted using the disable statement, in the 
same way that a named statement group or task can be disabled. 

Statement blocks 

a statement A begin...end block is a statement, and can therefore have either a 

block can have statement label or a block name, 
a name or a 

label begin: blockl // named block 
end: blockl 



block2: begin // labeled block 

end 



It is illegal to give a statement block both a label and a block name. 
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6.8 Enhanced case statements 



The Verilog case, casex, and casez statements allow the selec- 
tion of one branch of logic out of multiple choices. For example: 



always_comb 
case (opcode) 

2 ' bOO : 
2 ' bOl : 
2 ' blO : 
2 ' bll : 

endcase 



I case expression 
y = a + b; 
y=a-b; 
y = a * b; 
y = a / b; 



case selection 
items 



The expression following the case, casex, or casez keyword is 
referred to as the case expression . The expressions to which the 
case expression is matched are referred to as the case selection 
items. 

simulation and The Verilog standard specifically defines that case statements must 
synthesis might evaluate the case selection items in the order in which they are 

interpret case ij s t e( j This infers that there is a priority to the case items, the same 
statements 

differently as * n a ser * es °** if— else.. .if decisions. Software tools such as 
synthesis compilers will typically try to optimize out the additional 
logic required for priority encoding the selection decisions, if the 
tool can determine that all of the selection items are mutually exclu- 
sive. 

SystemVerilog provides special unique and priority modifiers 
to case, casex, and casez decisions. These modifiers allow an 
engineer to explicitly state that the decision sequence must be 
maintained (priority), or that software tools can optimize out the 
priority-encoded logic (unique). These modifiers are placed before 
the case, casex, or casez keywords: 

unique case 

priority case 



6.8.1 Unique case decisions 



a unique case 
can be 
evaluated in 
parallel 



The unique modifier indicates that the order of the case selection 
items is not significant, and the selections can be evaluated in paral- 
lel. Software tools can optimize out the inferred priority of the 
selection order. For example: 




158 



SystemVerilog for Design 



always_coxnb 

unique case (opcode) 
2'b00: y = a + b; 

2'b01: y = a - b; 

2 ' blO : y = a * b; 

2 ' bll : y = a / b; 

endcase 

Checking for unique conditions 

a unique case 
cannot have 
overlapping 
conditions 



In the following code snippet, a casez statement is used to allow 
specific bits of the selection items to be excluded from the compar- 
ison with the case expression. When specifying don’t care bits, it is 
easy to inadvertently specify multiple case selection items that 
could be true at the same time. In the example below, there are sev- 
eral potential overlapping case selection items: the first and third 
selection items could both be true, the first and fourth selection 
items could both be true, the second and third selection items could 
both be true, and the second and fourth selection items could both 
be true. 

always_comb 
casez (select) 

2 ' bl? : y = a + b; 

2'bO?: y = b - b; 

2 # b?0: y = a * b; // overlaps previous items 
2'b?l: y * a / b; // overlaps previous items 

endcase 

In the preceding example, the casez statement will compile with- 
out an error. If a case expression value could match more than one 
case selection item, then only the first matching branch is executed. 
No run-time error is generated to alert the designer or verification 
engineer of a potential design error. 

When the unique modifier is added, software tools will generate 
an error any time a case expression matches multiple case items. 



When a case, casex, or casez statement is specified as unique, 
software tools must perform additional semantic checks to verify 
that each of the case selection items is mutually exclusive. If a case 
expression value occurs during run time that could match more than 
one case selection item, the tool will generate a run-time error mes- 
sage. 
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always_comb 

unique casez (select) 

2 ' bl? : y = a + b; 

2 ' bO? : y b - b; 

2 ' b?0 : y = a * b; // ERROR due to overlap 
2 ' b?l : y = a / b; // ERROR due to overlap 

endcase 




Software tools may report an overlap error in unique case 
expression items at compile time, if the case items are all 
constant expressions. 



Detecting incomplete case selection lists 

a unique case When a case, casex, or casez statement is specified as unique, 
must specify all software tools will issue a run-time error if the value of the case 
conditions expression does not match any of the case selection items, and there 
is no default case. 

The following example will result in a run-time error if, during sim- 
ulation, opcode has a value of 3, 5, 6 or 7: 

bit [2:0] opcode; // 3 -bit wide vector 

alwayscoxnb 

unique case (opcode) 

3'bOOO: y = a + b; 

3'b001: y = a - b; 

3 ' bOlO : y = a * b; 

3 ' blOO : y = a / b; 
endcase 



Using unique case with always comb 

Both always_comb and unique case help ensure that the logic of 
a procedural block can be realized as combinational logic. There 
are differences in the checks that unique case performs and the 
checks that always_comb performs. The use of both constructs 
helps ensure that complex procedural blocks will synthesize as the 
intended logic. 

A unique case statement performs run-time checks to ensure that 
every case expression value that occurs matches one and only one 
case selection item, so that a branch of the case statement is exe- 
cuted for every occurring case expression value. An advantage of 
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6.8.2 

a priority case 
must evaluate in 
order 



a priority case 
must specify ail 
conditions 



run-time checking is that only the actual values that occur during 
simulation will be checked for errors. A disadvantage of run-time 
checking is that the quality of the error checking is dependent on 
the thoroughness of the verification tests. 

The always__comb procedural block has specific semantic rules to 
ensure combinational logic behavior during simulation (refer to 
sections 5.2.1 on page 108). Optionally, software tools can perform 
additional compile-time analysis of the statements within an 
always_comb procedural block to check that the statements con- 
form to general guidelines for modeling combinational logic. Hav- 
ing both the static checking of always_comb and the run-time 
checking of unique case helps ensure that the designer’s intent 
has been properly specified. 

Priority case statements 

The priority modifier indicates that the order of the case selec- 
tion items is important. Software tools must maintain the priority of 
the decision order. For example: 



always_comb 



priority case 


(l'bl) 


irqO : 


irq = 


4'b0001 


irql : 


irq = 


4'b0010 


irq2 : 


irq = 


4'b0100 


irq3 : 


irq = 


4'bl000 


endcase 







Because the model explicitly states that case selection items must 
be evaluated in order, all software tools will maintain the inferred 
priority encoding. Synthesis compilers will not try to optimize out 
the priority encoding when the priority modifier is specified. 

Preventing unintentional latched logic 

When the priority modifier is specified with a case, casex, or 
cases statement, all values of the case expression that occur during 
run time must have at least one matching case selection item. If 
there is no matching case selection item, a run-time error will 
occur. This ensures that when the case statement is evaluated, one, 
and only one, branch will be executed. The logic represented by the 
case statement can be implemented as combinational logic, without 
latches. 
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6.8.3 Unique and priority versus parallel_case and full_case 

The IEEE 1364.1 synthesis standard 1 for Verilog specifies special 
commands, referred to as pragmas, to modify the behavior of syn- 
thesis compilers. The 1364.1 pragmas are specified using the Ver- 
ilog attribute construct. Synthesis compilers also allow pragmas to 
be hidden within Verilog comments. 

synthesis One of the pragmas specified in the Verilog synthesis standard is 
parallei_case parallel_case. This instructs synthesis compilers to remove pri- 
pragma or jty enco ding, and evaluate all case selection items in parallel. 

always_comb 

(* synthesis, parallel_case *) 
case (opcode) 

2'b00: y = a + b; 

2'b01: y = a - b; 

2 ' blO : y = a * b; 

2 'bll : y = a / b; 

endcase 

synthesis Another pragma is f ull_case. This pragma instructs the synthesis 
fuil_case compiler that, for all unspecified case expression values, the out- 
pragma p Uts ass ig nec j within the case statement are unused, and can be opti- 
mized out by the synthesis compiler. 

always_comb 

(* synthesis, full__case *) 
case (State) 

3'b001: NextState = 3 ' boil- 
s' bOlO: NextState = 3'blOO; 

3 ' blOO : NextState = 3'b001; 

endcase 



unique and priority do more than synthesis pragmas 

The SystemVerilog unique and priority decision modifiers do 
more than the parallel_case and full_case pragmas. These 
modifiers reduce the risk of mismatches between software tools, 
and provide additional semantic checks that can catch potential 
design problems much earlier in the design cycle. 



1 . 1 364. 1 -2002 IEEE Standard for Verilog Register Transfer Level Synthesis. See page xxvii of 
this book for details. 
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unique case The unique case modifier combines the functionality of both the 
enforces parallel_case and full_case pragmas, plus added semantic 
semantic rules checking. The 1364.1 Verilog synthesis standard states that the 
parallel_case pragma will force a parallel evaluation, even if 
more than one case selection item will evaluate as true. This could 
result in more than one branch of a case statement executing at the 
same time. A case statement modified with unique will generate 
errors for overlapping case selection items. This ensures that a par- 
allel evaluation of the case statement will execute only one branch 
of the case statement. The unique modifier also performs run-time 
checks to help ensure that all possible case expression values have a 
matching case selection item. The parallel_case pragma does 
not impose any checking on the case selection items. 

priority case can The priority modifier provides the functionality of the 
prevent ful l_case synthesis pragma, plus additional semantic checks. 
mismatches when the ful l_case pragma is used, no assignment is made to 
the outputs of the case statement for the unspecified values of the 
case expression. In RTL simulations, these outputs will be 
unchanged, and reflect the value of previous assignments. In the 
gate-level design created by synthesis, the outputs will be driven to 
some optimized value. This driven value can be, and likely will be, 
different than the value of the outputs in the RTL model. This dif- 
ference can result in mismatches between pre-synthesis RTL simu- 
lations and post-synthesis gate-level simulations, if an unspecified 
case expression value is encountered. Equivalence checkers will 
also see a difference in the two models. 

The semantic checks provided by the unique and priority mod- 
ifiers help ensure that the logic within a case, casex, or cases 
statement will behave consistent with the intent specified by the 
designer. These restrictions can prevent subtle, difficult to detect 
logic errors within a design. 

The unique and priority modifiers are part of the language, 
instead of being an informational synthesis pragma (which is an 
attribute or comment). As part of the language, simulation, synthe- 
sis compilers, formal verification tools, lint checkers and other soft- 
ware tools can apply the same semantic rules, ensuring consistency 
across various tools. Synthesis pragmas modify how synthesis 
interprets the Verilog case statements, but they do not affect simu- 
lation semantics and might not affect the behavior of other software 
tools. This can lead to mismatches in how different tools interpret 
the same case statement. 
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6.9 Enhance d if...else decisions 

SystemVerilog extends the unique and priority decision modi- 
fiers to also work with if.. .else decisions. These modifiers can 
also reduce ambiguities with this type of decision, and can trap 
potential design errors early in the modeling phase of a design. 

The Verilog if ...else statement is often nested to create a series of 
decisions. For example: 

bit [2:0] sel; 
always_comb begin 

if (sel == 3'b001) mux__out = a; 

else if (sel == 3'bOlO) mux_out = b; 

else if (sel == 3 # bl00) mux__out = c; 

end 

In simulation, a series of if ...else.. .if decisions will be evaluated 
in the order in which the decisions are listed. To maintain the same 
ordering in hardware implementation, priority encoded logic would 
be required. Often, however, the specific order is not essential in 
the desired logic. The order of the decisions is merely the way the 
engineer happened to list them in the source code. Software tools 
such as synthesis may try to infer whether or not the priority- 
encoded logic is really necessary, and optimize the logic to parallel 
evaluations when the software tool deems that evaluation order is 
not essential to the logic functionality. 

6.9.1 Unique if...else decisions 

a unique if., .else The unique modifier indicates that the order of the decisions is not 
can be important. Software tools can optimize out the inferred priority of 

evaluated in t ^ e decision order. For example: 
parallel 

bit [2:0] sel; 

always_coxnb begin 

unique if (sel == 3'bOOl) mux_out = a; 

else if (sel == 3'b010) mux_out = b; 

else if (sel == 3'bl00) mux_out = c; 



simulation and 
synthesis might 
interpret if... else 
differently 



end 




164 



SystemVerilog for Design 



Checking for unique conditions 

a unique if... else Software tools will perform checking on a unique if decision 
cannot have sequence to ensure that all decision conditions in a series of 
^condiUo^ns else — if decisions are mutually exclusive. This allows the 
decision series to be executed in parallel, without priority encoding. 
A software tool will generate an error if it determines that more 
than one condition is true, or can be true. This error message can 
occur at either compile time or run-time. This additional checking 
can help detect modeling errors early in the verification of the 
model. 

In the following example, there is an overlap in the decision condi- 
tions. Any or all of the conditions for the first, second and third 
decisions could be true at the same time. This means that the deci- 
sions must be evaluated in the order listed, rather than in parallel. 
Because the unique modifier was specified, software tools can 
generate an error that the decision conditions are not mutually 
exclusive. 

bit [2:0] sel; 

always_comb begin 

unique if (sel [0] ) mux__out = a; 

else if (sel [1] ) mux_out = b; 

else if (sel [2]) mux_out = c; 

end 



Preventing unintentional latched logic 

a unique if. ..else When the unique modifier is specified with an if decision, soft- 
wares of wa re tools are required to generate a run-time warning if the if 

unspecified statement is evaluated and no branch is executed. The following 
conditions , A ° 

example would generate a run-time warning if the unique 

if. ..else.. .if sequence is entered and sel has any value other 

than 1, 2 or 4. 

always_comb begin 

unique if (sel == 3'bOOl) mux_out = a; 

else if (sel == 3'b010) mux_out = b; 

else if (sel == 3'bl00) mux_out = c; 

end 

This run-time semantic check guarantees that all conditions in the 
decision sequence that actually occur during run time have been 
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fully specified. When the decision sequence is evaluated, one 
branch will be executed. This helps ensure that the logic repre- 
sented by the decisions can be implemented as combinational logic, 
without the need for latches. 

6.9.2 Priority if decisions 

a priority if... else The priority modifier indicates that the order of the decisions is 
must evaluate in important. Software tools must maintain the order of the decision 
order se q Uence> p or example: 

always_comb begin 

priority if (irqO) irq = 4'b0001; 
else if (irql) irq = 4'b0010; 
else if (irq2) irq = 4'b0100; 
else if (irq3) irq = 4'bl000; 

end 

Because the model explicitly states that the decision sequence 
above must be evaluated in order, all software tools will maintain 
the inferred priority encoding. The priority modifier ensures 
consistent behavior from software tools. Simulators, synthesis com- 
pilers, equivalence checkers, and formal verification tools will all 
interpret the decision sequence in the same way. 

Preventing unintentional latched logic 

a priority if... else As with the unique modifier, when the priority modifier is 
must specify all specified with an if decision, software tools will perform run-time 
conditions that a branch is executed each time an if.. .else. ..if 

sequence is evaluated. A run-time error will be generated if no 
branch of a priority if...else...if decision sequence is exe- 
cuted. This helps ensure that all conditions in the decision sequence 
that actually occur during run time have been fully specified, and 
that when the decision sequences are evaluated, one, and only one, 
branch will be executed. The logic represented by the decision 
sequence can be implemented as priority-encoded combinational 
logic, without latches. 

Synthesis guidelines 

An if ...else.. .if decision sequence that is qualified with unique 
or priority is synthesizable. 
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6.10 Summary 



A primary goal of SystemVerilog is to enable modeling large, com- 
plex designs more concisely than was possible with Verilog. This 
chapter presented enhancements to the procedural statements in 
Verilog that help to achieve that goal. New operators, enhanced 
for loops, bottom-testing loops, and unique/priority decision 
modifiers all provide new ways to represent design logic with effi- 
cient, intuitive code. 




Chapter 7 

Modeling Finite State 
Machines with System Verilog 



OystemVerilog enables modeling at a higher level of abstraction 
O through the use of 2-state data types, enumerated types, and 
user-defined types. These are complemented by new specialized 
always procedural blocks, always_comb, always_ff and 
always_latch. These and other new modeling constructs have 
been discussed in the previous chapters of this book. 

This chapter shows how to use these new levels of model abstrac- 
tions to effectively model logic such as finite state machines, using 
a combination of enumerated types and the procedural constructs 
presented in the previous chapters. Using SystemVerilog, the cod- 
ing of finite state machines can be simplified and made easier to 
read and maintain. At the same time, the consistency of how differ- 
ent software tools interpret the Verilog models can be increased. 

This SystemVerilog features presented in this chapter include: 

• Using enumerated types for modeling Finite State Machines 

• Using enumerated types with FSM case statements 

• Using always_comb with FSM case statements 

• Modeling reset logic with enumerated types and 2-state data 
types 
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7.1 Modeling state machines with enumerated types 



Section 3.2 on page 52 introduced the enumerated type construct 
that SystemVerilog adds to the Verilog language. This section pro- 
vides additional guidelines on using enumerated types for modeling 
hardware logic such as finite state machines. 

enumerated Enumerated types provide a means for defining a variable that has a 
types have restricted set of legal values. The values are represented with names 
restricted values i ns tead of digital logic values. 

enumerated Enumerated types allow modeling at a higher level of abstraction, 
types allow a nd yet still represent accurate, synthesizable, hardware behavior. 
abstract Example 7-1 models a simple finite state machine (FSM), using a 
typical three-procedural block modeling style: one procedural block 
for incrementing the state machine, one procedural block to deter- 
mine the next state, and one procedural block to set the state 
machine output values. The example illustrates a simple traffic light 
controller. The three possible states are represented as enumerated 
type variables for the current state and the next state of the state 
machine. 

By using enumerated types, the only possible values of the state 
and Next variables are the ones listed in their enumerated type lists. 
The unique modifier to the case statements in the state machine 
logic helps confirm that the case statements cover all possible val- 
ues of the State and Next variables (unique case statements are 
discussed in more detail in section 6.8.1 on page 157). 

Example 7-1 : A finite state machine modeled with enumerated types 

module traf f ic_light (output bit green_l ight , 

yellow_light , 
red_light , 

input sensor, 

input [15:0] green__downcnt , 

yellow_downcnt , 
input clock, resetN) ; 

enum {RED, GREEN, YELLOW} State, Next; 

always_££ @(posedge clock, negedge resetN) 

if (! resetN) State <= RED; // reset to red light 
else State <= Next; 
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always_comb begin: set_nex testate 

Next = State; // the default for each branch below 
unique case (State) 

RED: if (sensor) Next = GREEN; 

GREEN: if (greenjiowncnt == 0) Next = YELLOW; 

YELLOW: if (yellow_downcnt == 0) Next = RED; 

endcase 

end: set_next_state 

always_comb begin: set_outputs 

{green_light , yellow__light , red__light} = 3'b000; 
unique case (State) 

RED: red__light = l'bl; 

GREEN: green_light = l'bl; 

YELLOW: yellow_light = l'bl; 
endcase 

end: set_outputs 

endmodule 



7.1.1 Representing state encoding with enumerated types 

The preceding example does not define any specific binary logic 
values for the names in the enumerated type list for state and 
Next. This is one of the advantages of enumerated types. The logic 
is represented at an abstract level, without having to specify imple- 
mentation details. 



enumerated 
types can have 
one-hot or other 
encoding 



Example 7-2 modifies the preceding example to explicitly represent 
one-hot encoding in the state sequencing. The only change between 
example 7-1 and example 7-2 is the definition of the enumerated 
type values. The rest of the state machine logic remains at an 
abstract level, using the names of the enumerated values. 



SystemVerilog’s enumerated types also allow modeling at a lower 
level of abstraction, so that specific state machine architectures can 
be represented. The digital logic value of each name in an enumer- 
ated type list can be specified. This allows explicitly representing 
one-hot, one-cold, Gray code, or any other type of state sequence 
encoding desired. 
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Example 7-2: Specifying one-hot encoding with enumerated types 



module traf f ic_light (output bit green__l ight , 

yellow_light , 
red_l ight # 

input sensor, 

input [15:0] green_downcnt , 
yellow__downcnt , 
input clock, resetN) ; 



enum bit [2:0] {RED = 3 # b001, 

GREEN = 3 ' bOlO , 

YELLOW = 3 'blOO} State, Next; 



always_ff @(posedge clock, negedge resetN) 

if (! resetN) State <= RED; // reset to red light 
else State <= Next; 



always__comb begin: set_next__state 

Next = State; // the default for each branch below 
unique case (State) 

RED: if (sensor) Next = GREEN; 

GREEN: if (green__downcnt == 0) Next = YELLOW; 

YELLOW: if (yellow_downcnt == 0) Next = RED; 

endcase 

end: set next state 



always_comb begin: set_outputs 

{green_light , yellow_light , red__light} = 3'b000; 
unique case (State) 

RED: red_light = l # bl; 

GREEN: green_light = l'bl; 

YELLOW: yellow_light = l'bl; 
endcase 

end : s e t__ou tpu t s 

endmodule 



7.1.2 Reversed case statements with enumerated types 

The typical use of a case statement is to specify a variable as the 
case expression, and then list explicit values to be matched as the 
list of case selection items. This is the modeling style shown in the 
previous two examples. 




Chapter 7: Modeling Finite State Machines with SystemVerilog 



171 



one-hot state Another style for modeling one-hot state machines is the reversed 
machines can case statement. In this style, the case expression and the case selec- 
use reversed t j on items are reversed. The case expression is specified as the lit- 
case s a emen s era j value to be matched, which is a 1-bit value of 1 for one-hot 
state machines. The case selection items are each bit of the state 
variable. In some synthesis compilers, using the reversed case style 
for one-hot state machines will yield more optimized synthesis 
results than the standard style of case statements. 

Example 7-3 illustrates using a reversed case statement style. In this 
example, a second enumerated type variable is declared that repre- 
sents the index number for each bit of the one-hot State register. 
The name r_bit, for example, has a value of 0, which corresponds 
to bit 0 of the State variable (the bit that represents the RED state). 

Example 7-3: One-hot encoding with reversed case statement style 

module traf f ic_light (output bit green_light, 

yellow_light , 
red_light , 

input sensor, 

input [15:0] green_downcnt , 
yellow_downcnt , 
input clock, resetN) ; 

enum {r_BIT =0, // index of RED state in State register 

G_BIT =1, // index of GREEN state in State register 
Y_BIT = 2} state _bit; 

enum {RED = 1<<R_BIT, // shift a 1 to that state's bit 

GREEN = 1«G__BIT, 

YELLOW = 1«Y_BIT) State, Next; 

always_ff @(posedge clock, negedge resetN) 

if (JresetN) State <= RED; // reset to red light 
else State <= Next; 

always_comb begin: set_next_state 

Next = State; // the default for each branch below 
unique case (l'bl) // reversed case statement 

State [R__BIT] : if (sensor) Next = GREEN; 

State [G_ BIT] : if (green_downcnt == 0) Next = YELLOW; 

State [Y_BIT] : if (yellowjdowncnt == 0) Next = RED; 

endcase 

end: set next state 




172 



SystemVerilog for Design 



always__coznb begin: set_ outputs 

{red__light, green_light, yellow_light } = 3'b000; 
unique case (l'bl) // reversed case statement 
State [R_BIT] : red_light = 1; 

State [G_BIT] : green_light = 1; 

State [Y_BIT] : yellow_light = 1; 
endcase 

end: set_outputs 

endmodule 



7.1.3 Enumerated types and unique case statements 

unique case The use of the unique modifier to the case statement in the preced- 

reduces the i n g example is important. Since a one-hot state machine only has 

ambiguities of one jjj t 0 f the state register set at a time, only one of the case selec- 
ise statements 

tion items will match the literal value of 1 in the case expression. 
The unique modifier to the case statement specifies three things. 

First, unique case specifies that all case selection items should be 
evaluated in parallel, without priority encoding. Software tools 
such as synthesis compilers can optimize the decoding logic of the 
case selection items to create smaller, more efficient implementa- 
tions. This aspect of unique case is the same as synthesis 
parallel_case pragma. 

Second, unique case specifies that there should be no overlap in 
the case selection items. During the run-time execution of tools 
such as simulation, if the value of the case expression satisfies two 
or more case selection items, a run-time error will occur. This 
semantic check can help trap design errors early in the design pro- 
cess. The synthesis parallel_case pragma does not provide this 
important semantic check. 

Third, unique case specifies that all values of the case expression 
that occur during simulation must be covered by the case selection 
items. This is similar to the full_case pragma for synthesis, but 
the synthesis pragma does not require that other tools perform any 
checking. With unique case, if a case expression value occurs 
that does not cause a branch of the case statement to be executed, a 
run-time error will occur. This semantic check can also help trap 
design errors much earlier in the design cycle. 
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7.1.4 Specifying unused state values 

standard data As an enumerated type, the state variable has a restricted set of 
types can have values. Had a built-in data type, such as bit or logic, been used 
unused values f or t h e state variable, many other values would have been possi- 
ble. A finite state machine with three states requires a 3-bit state 
register for one-hot encoding. This 3-bit register can contain 8 pos- 
sible values. A built-in data type variable such as bit or logic can 
represent all 8 of these values. There are two common modeling 
styles to indicate that some values of the case expression are not 
used: specify a default case selection with a logic X assignment, or 
specify a special synthesis ful l_case pragma. These two styles 
are discussed in more detail in the following paragraphs. 



Using X as a default assignment 



a default A common coding style with case statements is to specify a 
assignment ofX default statement to cover all unused values of the case expres- 
09 unused s * on ‘ default statement assigns a logic X to the variables 
conditions re P resen ^ n 8 the outputs of the case statement. In the FSM example 
from above, the case expression is the current state variable, 
State, and the output of the case statement is the next state vari- 
able, Next. 



// case statement without enumerated types 
logic [2:0] State, Next; 

case (State) 

3'bOOl: Next = 3'b010; 

3 ' bOlO : Next = 3'bl00; 

3 ' blOO : Next = 3'b001; 

default: Next = 3'bXXX; 
endcase 



In simulation, should the current state variable become an unex- 
pected value, the logic X assignment to the next state can serve as a 
flag that something is wrong. Synthesis compilers recognize the 
default assignment of logic X as an indication that any case expres- 
sion value that falls into the default case is an unused value. The 
logic for those unused values is optimized out of the synthesis 
results. 



assigning an X Assigning a logic X as the default output value will appear as an X 
can cause value in RTL simulation. Synthesis compilers will treat the X 
mismatches ass ig nme nt as a don’t care and optimize out the unused state values. 
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Using logic X as a default assignment requires the use of 4-state 
data types, such as reg or logic. 2-state data types such as bit 
cannot store a logic X. Section 7.2.3 on page 180, discusses this in 
more detail. 

Enumerated types eliminate the need for using a logic X assign- 
ment to show that not all case expression values are used. The enu- 
merated type limits the values of its variables to just the values 
listed in the enumerated value set. These are the only values that 
need to be listed in the case statement. The defined set of values 
that an enumerated type can hold, along with the additional unique 
case semantic checking (discussed in section 7.1.3 on page 172) 
help ensure that pre-synthesis RTL model and the post-synthesis 
gate-level model are the same for both simulation and equivalence 
checking. 

As discussed in the preceding paragraphs, using unique case 
combines the functionality of both the synthesis parallel_case 
and ful l__case pragmas. The unique case also provides seman- 
tic checks to ensure that all values of an enumerated variable used 
as a case expression truly meet the requirements to be implemented 
as parallel, combinational logic. Any unintended or unexpected 
case expression values will be trapped as run-time errors by a 
unique case statement. 

7.1.5 Assigning values to enumerated type variables 

enumerated Enumerated types are strongly typed variables. They can only be 

types can only assigned a value that is a member of the type list of that enumerated 
be assigned type In example 

7-2 on page 170, Next is first set to a default 
values in their *? x „ 

typeset v " ue t * iat 1S same as me current state variable. Because 

state and Next are of the same enumerated data type, it is legal to 

assign one variable to the other. The case statement then changes 

the default value of Next, if needed. The value assigned to Next is 

one of the names from the enumerated type list of Next, which is 

also a legal assignment. 

Another common style when using one-hot state sequences is to 
first clear the next state variable, and then set just the bit of Next 
that indicates what the next state will be. This style will not work 
with enumerated types. Consider the following code snippet: 



enumerated 
types can 
eliminate 
unused 
conditions 
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Example 7-4: Code snippet with illegal assignments to enumerated variables 

enum {R_BIT =0, // index of RED state in State register 

G_BIT =1, // index of GREEN state in State register 

Y_BIT = 2} state_bit ; 

enum {RED = 1<<R_BIT, // shift a 1 to that state's bit 

GREEN = 1<<G_BIT, 

YELLOW = 1«Y_BIT} State, Next; 



always_comb begin: set_next_state 

Next = 3'bOOO; // clear Next - ERROR: ILLEGAL ASSIGNMENT 
unique case (l'bl) // reversed case statement 
// WARNING: FOLLOWING ASSIGNMENTS ARE POTENTIAL DESIGN ERRORS 
State [R_BIT] : if (sensor == 1) Next [GJ3IT] = 1; 

State [G_BIT] : if (green__downcnt==0) Next [Y_BIT] = 1; 

State [Y_BIT] : if (yellow_downcnt==0) Next [R_BIT] = 1; 

endcase 

end: set next state 



There are two problems with the code snippet above. First, a default 
assignment of all zeros is made to the Next variable. This value 
does not exist in the enumerated list of values for Next, and will 
therefore result in an error. 

Second, within the case statements, assignments are made to indi- 
vidual bits of the Next variable. Assigning to a discrete bit of an 
enumerated variable may be allowed by compilers, but it is not a 
good style when using enumerated types. By assigning to a bit of an 
enumerated type variable, an illegal value could be created that is 
not in the enumerated type list. This would result in design errors 
that could be difficult to debug. 



Assign an enumerated type variable a name from its enumerated 

list, instead of a value. 

TIP 



Assignments to enumerated type variables should be from the list 
of names for that type. Assigning literal values to an enumerated 
type variable, or assigning to bit-selects or part-selects of an enu- 
merated variable should be avoided. When assignments to bits of a 
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variable are required, the variable should be declared as standard 
type, such as bit or logic, instead of an enumerated type. 

7.1.6 Performing operations on enumerated type variables 

Enumerated types differ from most other Verilog data types in that 
they are strongly typed variables. For example, it is illegal to 
directly assign an integer value to an enumerated type. When an 
operation is performed on an enumerated type variable, the value of 
the variable is the data type of the names within the enumerated 
type list. By default, this is an int data type, but can be explicitly 
declared as other data types. 

The following example will result in an error. The operation state 
+ 1 will result in an int value. Directly assigning this int value to 
the Next variable, which is an enumerated type variable, is illegal. 

enum {RED, GREEN, YELLOW} State, Next; 

Next = State +1; // ILLEGAL ASSIGNMENT 

This error can be overcome using type casting. SystemVerilog pro- 
vides both a static cast operator and a dynamic cast system func- 
tion. 

typedef enum {RED, GREEN, YELLOW} states_t; 
states_t State, Next; 

Next = states_t' (State + 1) ; // static cast 

$cast(Next, State + 1); // dynamic cast 

A static cast operation coerces an expression to a new data type 
without performing any checking on whether the value coerced is a 
valid value for the new data type. If, for example, the current value 
of State were YELLOW, then State + 1 would result in an out-of- 
bounds value. Using static casting, this out-of-bounds value would 
not be trapped. The SystemVerilog standard allows software tools 
to handle out-of-bounds assignments in a nondeterministic manner. 
This means the new value of the Next variable in the preceding 
static cast assignment could, and likely will, have different values 
in different software tools. 

A dynamic cast performs run-time checking on the value being 
cast. If the value is out-of-range, then an error message is gener- 
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ated, and the target variable is not changed. By using dynamic cast- 
ing, inadvertent design errors can be trapped, and the design 
corrected to prevent the out-of-bounds values. 

SystemVerilog also provides a number of special enumerated type 
methods for performing basic operations on enumerated type vari- 
ables. These methods allow incrementing or decrementing a value 
within the list of legal values for the enumerated type. 

Next = State. next; // enumerated method 

Section 3.2.8 on page 61 discusses the various enumerated methods 
in more detail. 

Each of these styles of changing an enumerated variable has advan- 
tages. Assigning a value that is one of the names in the enumerated 
type list is intuitive and requires no casting. The dynamic cast oper- 
ator provides run-time errors for out-of-range values. Using the 
enumerated type methods ensures the assigned value will always be 
within the set of values in the enumerated type list. Static casting 
does not perform any error checking, but can be resolved, and pos- 
sibly optimized, at compile time. 



7.2 Using 2-state data types in FSM models 



7.2.1 2-state data type characteristics 

SystemVerilog SystemVerilog adds several 2-state data types to the Verilog lan- 
adds 2-state guage: bit (1-bit wide), byte (8-bits wide), short in t (16-bits 
data types wide), int (32-bits wide) and longint (64-bits wide). These 2- 
state types allow modeling designs at an abstract level, where tri- 
state values are seldom required, and where circuit conditions that 
can lead to unknown or unpredictable values — represented by a 
logic X — rarely occur. 



2-state and 
4-state types 
can be mixed 



For the rare times that 4-state logic may be required at an abstract 
modeling level, SystemVerilog allows freely mixing 2-state and 4- 
state data types within a module. This enables the designer to spec- 
ify 2-state types for most of a design, where only 2-state based val- 
ues are needed, and still use 4-state data types where tri-state buses 
or other 4-state logic is required in the design. 
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mapping 4-state Verilog is a loosely-typed language, and this characteristic is also 
values to 2-state true for SystemVerilog’s 2-state data types. Thus, it is possible to 
assign a 4-state value to a 2-state data type. When this occurs, the 4- 
state value is mapped to 2-states as shown in the following table: 



Table 7-1 : Conversion of 4-state values to 2-state values 



4-state Value 


Converts To 


0 


0 


1 


1 


z 


0 


X 


0 



7.2.2 2-state data types versus 2-state simulation 

tool-specific 2- Some software tools, simulators in particular, offer a 2-state mode 
state modes for when the design models do not require the use of logic Z or X. 

These 2-state modes allow simulators to optimize simulation data 
structures and algorithms and can achieve faster simulation run 
times. SystemVerilog’s 2-state data types permit software tools to 
make the same types of optimizations. However, SystemVerilog’s 
2-state data types have important advantages over 2-state simula- 
tion modes. 

SystemVerilog The software tools that provide 2-state modes typically use an invo- 
standardizes cation option to specify using the 2-state mode algorithms. Invoca- 
mixing 2-state tion options are often globally applied to all files listed in the 
and 4-state data invocation command. This makes it difficult to have a mix of 2- 
types state j 0 gj c an( j 4- s tate logic. Some software tools provide a more 
flexible control, by allowing some modules to be compiled in 2- 
state mode, and others in the normal 4-state mode. These tools may 
also use tool-specific pragmas or other proprietary mechanisms to 
allow specific variables within a module to be specified as using 2- 
state or 4-state modes. All of these proprietary mechanisms are 
tool-specific, and differ from one software tool to another. System- 
Verilog’s 2-state data types give the designer a standard way to 
specify which parts of a model should use 2-state logic and which 
parts should use 4-state logic. 
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SystemVerilog With 2-state simulation modes, the algorithm for how to map a 
2-state to 4 - logic Z or logic X value to a 2-state value is proprietary to the soft- 
state mapping is ware tool, and is not standardized. Different simulators can, and do, 
standardized ma p va i ue s differently. For example, some commercial simulators 
will map a logic X to a 0, while others map a logic X to a 1 . The dif- 
ferent algorithms used by different software tools means that the 
simulation results of the same model may not be the same. System- 
Verilog’s 2-state data types have a standard mapping algorithm, 
providing consistent results from all software tools. 

SystemVerilog Another difference between 2-state modes and 2-state data types 
2-state involves the initialization of a variable to its 2-state value. The 
initialization is IEEE 1364 Verilog standard specifies that 4-state variables begin 
standardized simulation with a logic X, indicating the variable has not been ini- 
tialized. The first time the 4-state variable is initialized to a 0 or 1 
will cause a simulation event, which can trigger other activity in the 
design. Whether or not the event propagates to other parts of the 
design depends in part on nondeterministic event ordering. Most of 
the proprietary 2-state mode algorithms will change the initial value 
of 4-state variables to be a logic 0 instead of a logic X, but there is 
no standard on when the initialization occurs. Some simulators with 
2-state modes will set the initial value of the variable without caus- 
ing a simulation event. Other simulators will cause a simulation 
event at time zero as the initial value is changed from X to 0, which 
may propagate to other constructs sensitive to negative edge transi- 
tions. The differences in these proprietary 2-state mode algorithms 
can lead to differences in simulation results between different soft- 
ware tools. The SystemVerilog 2-state variables are specifically 
defined to begin simulation with a logic value of 0 without causing 
a simulation event. This standard rule ensures consistent behavior 
in all software tools. 

The Verilog casez and casex decision statements can be affected 
by 2-state simulation modes. The casez statement treats a logic Z 
as a don’t care value instead of high-impedance. The casex state- 
ment treats both a logic X and a logic Z as don’t care. When a pro- 
prietary 2-state mode algorithm is used, there is no standard to 
define how casez and casex statements will be affected. Further- 
more, since these simulation modes only change the 4-state behav- 
ior within one particular tool, some other tool that might not have a 
2-state mode might interpret the behavior of the same model differ- 
ently. SystemVerilog’s standard 2-state data types have defined 
semantics that provide deterministic behavior with all software 
tools. 



SystemVerilog 
2-state affects 
on casez and 
casex is 
standardized 
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7.2.3 Using 2-state types with case statements 



At the abstract RTL level of modeling, logic X is often used as a 
flag within a model to show an unexpected condition. For example, 
a common modeling style with Verilog case statements is to make 
the default branch assign outputs to a logic X, as illustrated in the 
following code fragment: 



case (State) 

RESET: Next = WAIT 

WAIT: Next = LOAD 

LOAD: Next = DONE 

DONE: Next = WAIT, 

default: Next = 4'bx, 

endcase 



// unknown state 



The default assignment of a logic X serves two purposes. Synthesis 
treats the default logic X assignment as a special flag, indicating 
that, for any condition not covered by the other case selection 
items, the output value is “don’t care”. Synthesis will optimize the 
decode logic for the case selection items, without concern for what 
is decoded for case expression values that would fall into the 
default branch. This can provide better optimizations for the explic- 
itly defined case selection items, but at the expense of indetermi- 
nate results, should an undefined case expression value occur. 

Within simulation, the default assignment of logic X serves as an 
obvious run-time error, should an unexpected case expression value 
occur. This can help trap design errors in the RTL models. How- 
ever, this advantage is lost after synthesis, as the post-synthesis 
model will not output logic X values for unexpected case expres- 
sion values. 



Assigning a logic X to a 2-state variable is legal. However, the 
assignment of a logic X to a variable will result in the variable hav- 
ing a value of 0 instead of an X. If the state or Next variables are 
2-state data types, and if a value of 0 is a legitimate value for state 
or Next, then the advantage of using an X assignment to trap 
design errors at the RTL level is lost. The default X assignment will 
still allow synthesis compilers to optimize the decode logic for the 
case selection items. This means that the post-synthesis behavior of 
the design will not be the same, because the optimized decoding 
will probably not result in a 0 for undefined case expression values. 
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When enumerated types are used, an assignment of logic X to a 
State or Next variable will only be legal if a value of all bits set to X 
exists in the enumerated type list for the variable. Otherwise, the 
assignment will be an out-of-bounds assignment, as discussed in 
section 7.1.5 on page 174. 

7.2.4 Resetting FSMs with 2-state and enumerated variables 

At the beginning of simulation, 4-state data types are logic X. 
Within a model such as a finite state machine, a logic X on 4-state 
variables can serve as an indication that the model has not been 
reset, or that the reset logic has not been properly modeled. 

2-state data types begin simulation with a default value of logic 0 
instead of an X. Since the typical action of reset is to set most vari- 
ables to 0, it can appear that the model has been reset, even if there 
is faulty reset logic. 

Enumerated types begin simulation with a default value of the first 
item in the enumerated list. If reset also sets enumerated values to 
the first item in the list, then a similar situation can occur as with 2- 
state variables. The design can appear to have been reset, even if 
reset is never asserted, or if the reset logic has errors. 

Asserting reset at the beginning of simulation 

2-state variables and enumerated type variables begin simulation 
with known values. A 2-state variable begins with a logic 0, and an 
enumerated type variable begins with the first item in its enumera- 
tion list. If a reset at the beginning of simulation sets these variables 
to the same value as they begin simulation with, there will be no 
transition to trigger other activity. 

The following example will lock-up in the wait state. This is 
because both the State and Next variables begin simulation with 
the first value in their enumerated lists, which is WAIT. At every 
positive edge of clock, State is assigned the value it already has, 
and therefore no transition occurs. Since there is no transition, the 
always @ (State) procedural block that decodes Next is not trig- 
gered, and therefore Next is not changed from its initial value of 
WAIT. 

enum {WAIT, LOAD, STORE} State, Next; 
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always @(posedge clock, negedge resetN) 
if (! resetN) State <= WAIT; 
else State <= Next; 

always @ (State) 
case (State) 

WAIT: Next = LOAD; 

LOAD: Next = STORE; 

STORE: Next = WAIT; 

endcase 

Applying reset does not fix this state lock-up problem. Reset 
changes the state variable to wait, which is the same value that 
State begins simulation with. Therefore there is no change to the 
State variable and the next state decode logic is not triggered. 
Next continues to keep its initial value, which is also wait. 

This lock-up at the start of simulation can be fixed by replacing 
always ©(state) with the SystemVerilog always_comb proce- 
dural block. An always_comb procedural block automatically exe- 
cutes its statements once at simulation time zero, even if there were 
no transitions on its inferred sensitivity list. By executing the 
decode logic at time zero, the initial value of State will be 
decoded, and the Next variable set accordingly. This fixes the start 
of simulation lock-up problem. 



7,3 Summary 



This chapter has presented suggestions on modeling techniques 
when representing hardware behavior at a more abstract level. Sys- 
temVerilog provides several enhancements that enable accurately 
modeling designs that simulate and synthesize correctly. These 
enhancements help to ensure consistent model behavior across all 
software tools, including lint checkers, simulators, synthesis com- 
pilers, formal verifiers, and equivalence checkers. 

Several ideas were presented in this section on how to properly 
model finite state machines using these new abstract modeling con- 
structs such as: 2-state date types, enumerated data types, 
always__comb procedural blocks, and unique case statements. 




Chapter 8 

SystemVerilog 
Design Hierarchy 



r his chapter presents the many enhancements to Verilog that 
SystemVerilog adds for representing and working with design 
hierarchy. The topics that are discussed include: 



• Module prototypes 

• Nested modules 

• Simplified netlists of module instances 

• Netlist aliasing 

• Passing values through module ports 

• Port connections by reference 

• Enhanced port declarations 

• Parameterized data types and polymorphism 

• Variable declarations in blocks 
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8,1 Module prototypes 



module A module instance in Verilog is a straight-forward and simple 
instances need method of creating design hierarchy. For tool compilers, however, 
more info to be it is difficult to compile a module instance, because the definition of 
compiled the module and its ports is in a different place than the module 
instance. To complete the compilation process of a module 
instance, the compiler must also at least parse the module definition 
in order to determine the number of ports and the order of the ports 
in the module definition. 

extern module SystemVerilog simplifies the compilation process by allowing 
declarations users to specify a prototype of the module being instantiated. The 
prototype is defined using an extern keyword, followed by the 
declaration of a module and its ports. Either the Verilog- 1995 or the 
Verilog-2001 style of module declarations can be used for the pro- 
totype. The Verilog- 1995 module declaration style is limited to 
only defining the number of ports and port order of a module. The 
Verilog-2001 module declaration style defines the number of ports, 
the port order, the port vector sizes and the port data types. Verilog- 
2001 style module declarations can also include a parameter list, 
which allows parameterized ports. Examples of Verilog- 1995 and 
Verilog-2001 prototype declarations are: 

// prototype using Verilog-1995 style 
extern module counter (cnt, d, clock, resetN) ; 



// prototype using Verilog-2001 style 
extern module counter # (parameter N = 15) 

(output logic [N : 0] cnt, 
input wire [N : 0] d, 
input wire clock, 
load 
resetN) ; 

Prototypes of a module definition also serve to document a design. 
Large designs can be spread across dozens of source files. When 
one file contains an instance of another module, some other file 
needs to be examined to see the definition of the instantiated mod- 
ule. A prototype of the module definition can be listed in the same 
file in which the module is instantiated. 




Chapter 8: SystemVerilog Design Hierarchy 



185 



Extern module declaration visibility 

prototypes are The extern module declaration can be made in any module, at 
local to the any level of the design hierarchy. The declaration is only visible 
containing within the scope in which it is defined. An external module declara- 
scope tion that is made outside of any module boundary will be globally 
visible. Any other module, anywhere in the design hierarchy can 
instantiate the globally visible module. 

In Verilog, modules can be instantiated before they are defined. 
The prototype for a module is an alternative to the actual definition 
in a compilation unit, and therefore uses a similar checking system. 
It is not necessary for the extern declaration to be encountered 
prior to an instance of the module. 

8.1.1 Prototype and actual definition 

prototype and SystemVerilog requires that the port list of an extern module dec- 
actual definition laration exactly match the actual module definition, including the 
must match order of the ports and the port sizes. It is a fatal error if there is any 
mismatch in the port lists of the two definitions. 

8.1.2 Avoiding port declaration redundancy 

module SystemVerilog provides a convenient shortcut to reduce source 
definition can code redundancy. If an extern module declaration exists for a 
use . * shortcut module, it is not necessary to repeat the port declarations as part of 
the module definition. Instead, the actual module definition can 
simply place the . * characters in the port list. Software tools will 
automatically replace the . * with the ports defined in the extern 
module prototype. This saves having to define the same port list 
twice, once in the external module prototype, and again in the 
actual module definition. For example: 

extern module counter # (parameter N = 15) 

(output logic [N: 0] cnt, 
input wire [N : 0] d, 
input wire clock, 
load 
resetN) ; 



module counter ( . * ) ; 

always @(posedge clock, negedge resetN) begin 
if (! resetN) cnt <= 0; 




186 



SystemVerilog for Design 



else if (load) cnt <= d; 
else cnt <= cnt + 1; 

end 

endmodule 

In this example, using . * for the counter module definition infers 
both the parameter list and the port list from the extern declara- 
tion of the counter. 



8.2 Named module end 



A module is defined between the pair of keywords module and 
endmodule. With the addition of nested modules, a parent module 
can contain multiple endmodule declarations. This can make it dif- 
ficult to read a large block of code, and determine visually which 
endmodule is paired with which module declaration. 

SystemVerilog allows a name to be specified with the endmodule 
keyword, using the form: 

endmodule : < modu 1 e_name > 

The name specified with endmodule must be the same as the name 
of the module with which it is paired. 

Specifying a name with endmodule serves to make SystemVerilog 
code self-documenting and easier to maintain. Several of the larger 
SystemVerilog code examples in this book illustrate named module 
ends. 

SystemVerilog also allows an ending name to be specified with 
other named blocks of code. These include the block pairs: inter - 
f ace.. .endinter face, task...endtask, function. ..endf unc- 
tion, begin.. .end, fork.. .join, fork...join_any and 

f or k. . . j o in_none . 

Section 6.6 on page 1S3 discusses begin.. .end pairs and 
fork... join pairs in more detail. 
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8,3 Nested (local) module declarations 

module names In Verilog, all module names, user-defined primitive (UDP) names, 
are global and system task and system function names (declared using the 
Verilog PLI) are placed in a global name scope. The names of these 
objects can be referenced anywhere in the design hierarchy. This 
global access to module names provides a simple yet powerful 
mechanism for defining the design hierarchy. Any module can 
instantiate any other module, without dependencies on file order 
compilation. 

access to However, Verilog’s global access to all elaborated module names 
module names makes it impossible to limit access to specific modules. If a com- 
is not restricted plex Intellectual Property model, for example, contains its own 
hierarchy tree, the module names within the IP model will become 
globally accessible, allowing any other part of a design to directly 
instantiate the submodules of the IP model. 

global names Verilog’s global access to all elaborated module names can also 
can cause result in naming conflicts. For example, if both the user’s design 
conflicts and an IP model contained modules named fsm , there would be a 
name collision in the global name scope. If multiple IP models are 
used in the design, it is possible that a module name conflict will 
occur between two or more IP models. A name conflict will require 
that changes be made to either the IP model source code or the 
design code. 

Most software tools provide proprietary solutions for name scope 
conflict. These solutions, however, usually require some level of 
user input over the compilation and/or elaboration process. Verilog- 
2001 adds a configuration construct to provide a standard solution 
for allowing the same module name to be used multiple times, with- 
out a conflict in the global module definition name scope. Configu- 
rations, however, are verbose, and do not address the problems of 
limiting where a module can be instantiated. 

Nested (local) modules 

modules SystemVerilog provides a simple and elegant solution for limiting 
declared within where module names can be instantiated, and avoiding potential 
modules conflicts with other modules of the same name. The solution is to 
allow a module definition to be nested within another module defi- 
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nition. Nested modules are not visible outside of the hierarchy 
scope in which they are declared. For example: 

Example 8-1: Nested module declarations 

module chip (input wire clock) ; // top level of design 

dreg il (clock) ; 
ip_core i2 (clock) ; 
endmodule : chip 

module dreg (input wire clock) ; // global module definition 

endmodule: register 

module ip_core (input wire 
subl ul (...); 
sub2 u2 (...); 
module subl (...); 

endmodule : subl 

module sub2 ( . . . ) ; // nested module definition 

endmodule : sub2 
endmodule : ip_core 



clock) ; // global module definition 

// nested module definition 



The instantiated hierarchy tree for example 8-1 is: 







Chapter 8: SystemVerilog Design Hierarchy 



189 



Nested module definitions can be in separate files 

A very common modeling style with Verilog is to place the source 
code for each module definition in a separate source file. Typically, 
the file name is the same as the module name. This style, while not 
a requirement of the Verilog language, is often used, because it 
helps to develop and maintain the source code of large designs. If 
several modules are contained in a single file, the source code 
within that file can become unwieldy and difficult to work with. 
Keeping each module in a separate file also facilitates the use of 
revision control software as part of the design process. Revision 
control tools allow specific users to check out specific files for 
modification, and can track the revision history of that file. If many 
modules are contained in the same file, revision control loses some 
of its effectiveness. 



[Tp Use 'include to avoid the convoluted code of multiple 

^ — T modules in the same source code file. 

TIP 

Nesting module definitions can lead to the source code for the top- 
level module spanning a large number of lines of code, with multi- 
ple module definitions in a single file. In addition, a nested module 
can become difficult to maintain, or to reuse in other designs, if the 
source code of the nested module is buried within the top-level 
module. 

Using Verilog’s 'include compiler directive with nested modules 
can eliminate these potential drawbacks. The definition of each 
nested module can be placed in a separate file, where it is easy to 
maintain and to reuse. The top-level module can then include the 
definitions of the nested module, using ' include directives. This 
helps make the top-level module more compact and easier to read. 

For example: 

module ip_core (input bit clock) ; 

'include subl.v // subl is a nested module 
'include sub2.v // sub2 is a nested module 

endmodule 
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module subl ( . . . ) ; // stored in file subl.v 

endmodule 



module sub2 ( . . . ) ; // stored in file sub2.v 

endmodule 

8.3.1 Nested module name visibility 

nested module The names of nested modules are not placed in the global module 
names are not definition name scope with other module names. Nested module 
global names exist in the name scope of the parent module. This means 
that a nested module can have the same name as a module defined 
elsewhere in a design, without any conflict in the global module 
definition name scope. 

Because the name of a nested module is only visible locally in the 
parent module, the nested module name can only be instantiated by 
the parent module, or the hierarchy tree below the nested module. A 
nested module name cannot be instantiated anywhere else in a 
design hierarchy. In example 8-1, above, the modules chip, dreg, 
and ip__core are in the global name scope. These modules can be 
instantiated by any other module, anywhere in the design hierarchy. 
Modules subl and sub2 are nested within the definition of the 
ip^core module. These module names are local names within 
ip_core, and can only be instantiated in ip_core, or by the mod- 
ules that are instantiated in ip_core. 

nested module Nested modules have a hierarchical scope name, the same as with 
hierarchy paths any module instance. Variables, nets, and other declarations within 
a nested module can be referenced hierarchically for verification 
purposes, just as with declarations in any other module in the 
design. 

Nested modules can instantiate other modules 

nested modules A nested module can instantiate other modules. The definitions of 
can instantiate these modules can be in three name scopes: the global module defl- 
ower modules nition name scope, the parent of the nested module, or within the 
nested module (as another nested module definition). 
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8.3.2 Instantiating nested modules 

nested modules A nested module is instantiated in the same way as a regular mod- 
are instantiated ule. Nested modules can be explicitly instantiated any number of 
the same as times within its parent. It can also be instantiated anywhere in the 
regular modules hierarchy tree below the parent module. The only difference 
between an instance of a nested module and a regular module is that 
the nested module can only be instantiated in the hierarchy tree at 
or below its parent module, whereas a regular module can be 
instantiated anywhere in the design hierarchy. 

In the following example, module ip_core has three nested mod- 
ule definitions: subl, sub2, and sub3. Even though the nested 
module definitions are local to ip_core, hierarchically, these 
nested modules are not all direct children of ip_core. In this 
example, ip_core instantiates module subl, subl instantiates 
sub2, and sub2 instantiates sub3. 

Example 8-2: Hierarchy trees with nested modules 
module ip__core (input clock) ; 

subl ul (...) ; // instance of nested module subl 

module subl (...); // nested module definition 

sub2 u2 ( ) / 

endmodule : subl 

module sub2; // nested module definition 

// sub2 does not have ports, but will look in its source 
// code parent module (ip_core) for identifiers 
sub3 u3 (...); 
endmodule : sub 2 

module sub3 (...); // nested module definition 

endmodule : sub 3 
endmodule : ip_core 
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The instantiated hierarchy tree for example 8-2 is: 




8.3.3 



nested modules 
have a local 
scope 



nested modules 
can reference 
names in their 
parent module 



modules that 
are not nested 
search upward 
in the 

instantiation tree 



Nested module name search rules 

A nested module has its own name scope, just as with regular mod- 
ules. Nested modules can be defined either with ports or without 
ports. The port names of a nested module become local names 
within the nested module. Any nets, variables, tasks, functions or 
other declarations within a nested module are local to that module. 

Nested modules have a different name search rule than regular 
modules. Semantically, a nested module is similar to a Verilog task, 
in that the nested module has visibility to the signals within its par- 
ent. As with a task, if a name is referenced that is not in the local 
scope of the nested module, that name will be searched for in the 
parent module. If a name is referenced that is not local to the nested 
module and also does not exist in the parent module, the compila- 
tion-unit scope will be searched. This allows a nested module to 
reference variables, constants, tasks, functions, and user-defined 
types that are defined externally, in the compilation-unit. 

It is important to note that the upward searching of a nested module 
is different than the upward searching rules of modules that are not 
nested. A module that is not nested is in the global module defini- 
tion scope. There is no source code parent. When a module that is 
defined in the global module definition scope references an identi- 
fier (such as a variable name or function, that is not declared within 
the module) the name search path uses the instantiation hierarchy 
tree, including the compilation-unit scope. 
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nested modules A nested module definition, on the other hand, does have a source- 
search upward code parent. When an identifier is referenced within a nested mod- 
in the source u i e that is not defined within the nested module, the search path is 
code look j n parent module where the nested module is defined, 
rather than where the module is instantiated. 



8,4 Simplified netlists of module instances 



netlists connect A netlist is a list of module instances, with nets connecting the ports 
module of the instances together. Netlists are used at many levels of design, 
instances from connecting major blocks together at a high-level of abstrac- 
together tion, to connecting together discrete components, such as ASIC 
cells or gates at a detailed implementation level. Netlists are often 
generated from software tools, such as synthesis compilers; but 
netlists are also often defined by hand, such as when connecting 
major design blocks together. Even at the block level, with abstract 
high-level models, netlists can often be quite large, with a high 
potential for connection errors that can be difficult to debug. 

The Verilog language provides two syntax styles for connecting 
module instances together: ordered port connections and named 
port connections . 

using port order Ordered port connections connect a net or variable to a module 
to connect instance, using the position of the ports of each module definition. 

module For example, a net called data Jdus might connect the fifth port of 
instances one module instance to the fourteenth port of another module 
instance. With ordered port connections, the names of each port do 
not matter. It is the port position that is critical. This requires know- 
ing the exact order of the ports for each module instance being con- 
nected. 

The requirement to know the exact position of each port of the 
module being instantiated is a disadvantage. Unintentional design 
errors can easily occur when using the port order connection syn- 
tax. Modules in complex designs often have dozens of ports. 
Should a net be connected to the wrong port position, the error will 
not be obvious from just looking at the netlist. Another disadvan- 
tage is that ordered port connections do not clearly document the 
design intent. It is difficult to look at a module instance that is con- 
nected by port order and determine to which port a net is intended 
to be connected. Because of these disadvantages, many companies 
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discourage the use of ordered port connections in their company 
style guidelines. 

using port The second style for connecting modules together in Verilog is to 
names to specify the name of each port explicitly, along with the name of the 
connect module signal that is connected to that port. The basic syntax for each port 
instances connection is: 

. <port_name> (<net_or_variable_name>) 

Using this named port connection style, it is not necessary to main- 
tain the order of the ports for each module instance. By using 
named port connections, the potential for inadvertent design errors 
is reduced, since each port is explicitly connected to a specific net. 

Example 8-3 shows a netlist for a small microprocessor, which rep- 
resents a simplified model of a Microchip PIC 8-bit processor. 
Though it is a small design with just 6 module instances in the 
netlist, the model illustrates using named port connections. Exam- 
ples 8-4 and 8-5, which follow, show how SystemVerilog simpli- 
fies Verilog netlists. 



Example 8-3: Simple netlist using Verilog’s named port connections 

module mini PIC ( 

inout wire [7:0] port_a_pins, 
inout wire [7:0] port__b_pins , 
inout wire [7:0] port_c_pins, 
input wire elk, 

input wire resetN 

>; 



wire 

wire 

wire 



wire 

wire 

wire 

wire 



[11:0] instruct_reg, program_data; 

[10:0] program_counter, program_address; 

[ 7:0] tmr0_reg, status_reg, fsr_reg, w_reg, option_reg, 
reg_f ile__out, port_a, port_b, port_c, trisa, 
trisb, trisc, data_bus, alu_a, alu_b; 

[ 6:0] reg_f ile__addr; 

[ 3:0] alu_opcode ; 

[ 1:0] alu_a__sel, alu_b_sel; 

reg_f ile_sel , special__reg_sel , reg_f ile_enable, 
w_reg_enable, zero_enable, carry_enable , skip, 
isoption, istris, polarity, carry, zero; 
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pc_stack pcs ( // module instance with named port connections 
.program__counter (program__counter) , 

.progratn_address (program_address) , 

.elk (elk) f 
. resetN(resetN) , 

. instruct_reg ( instruct_reg) , 

.data__bus (data__bus) , 

. status_reg (status_reg) 

>; 



prom prom ( 

.dout (program_data) , 
.clk(clk) , 

.address (program__address) 

) ; 

instruct ion_decode decoder ( 

. alu_opcode (alu_jDpcode) , 

. alu_a__sel (alu_a_sel) , 
.alu_jD_sel (alu_b_sel) , 

. w_r eg__enab 1 e ( w_r eg_enab 1 e ) , 
• re g_file__sel (reg_f ile_sel) , 
. zero_enable (zero_enable) , 

. carry__enable (carry_enable) , 
.polarity (polarity) , 

.option (isoption) , 

. tris (istris) , 

. instruct__reg ( instruct__reg) 

) ; 

register^f iles regs ( 

. dout (reg_f ile__out) , 

. tmrO_reg (tmrO__reg) , 

. status_reg (status_reg) , 

. f sr_reg (f sr_reg) , 

.port_a (port_a) , 

.port_b (port_b) , 

.port_c (port_c) , 

. trisa (trisa) , 

. trisb (trisb) , 

. trisc (trisc) , 

. option_reg (option__reg) , 

. w_reg (w__reg) , 

. instruct_reg ( instruct_reg) , 
.program_data (program_data) , 
.port_a_j?ins (port__a_pins) , 
.data_bus (data_bus) , 

.address (reg__f ile__addr) , 
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. elk (elk) , 

.resetN(resetN) , 

. skip (skip) , 

•reg — file_sel (reg__f ile_sel) , 

. zero_enable (zero_enable) , 

. carry_enable (carry_enable) , 

. w__reg_enable (w_reg_enable) , 

. reg_f ile_enable (reg__f ile_enable) , 
. zero (zero) , 

.carry (carry) , 

. special_reg_sel (special_reg_sel) , 
. isoption(isoption) , 

. istris (istris) 



alu alu ( 

.y (data_bus) , 

.carry_out (carry) , 

. zero_out (zero) , 

.a (alu_a) , 

.b(alu_b) f 

.opcode (a lu_opcode) , 

. carry_in (status_reg [0] ) 

) ; 



glue__logic glue ( 

.port_b_j?ins (port_b_pins) , 
,port_c_pins (port_c__pins) , 

,alu_a (alu_a) , 

. alu_b (alu_b) , 

. expan_out (expan_out) , 

. expan__addr (expan_addr) , 

. r eg_f i 1 e_addr ( reg_f i 1 e_addr ) , 

. reg_f ile_enable (reg_f ile_enable) , 
. special_reg_sel (special_reg_sel) , 
. expan_read(expan_read) , 

. expan_write (expan_write) , 

. skip (skip) , 

. instruct_reg (instruct_reg) , 

. program_counter (program_counter) , 
.port_a (port_a) , 

.port_b (port__b) , 

.port_c (port_ c) , . 

.data_bus (data_bus) , 

. expan_in (expan__in) , 

. fsr__reg (f sr__reg) , 
.tmrO_reg(tmrO_reg) , 
.status_reg(status_reg) # 
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. w_reg (w_reg) , 

. reg_f ile__out (reg_f ile_out) , 
. alu_a__ sel (alu_a_sel) , 
.alu_b_sel (alu_b__sel) , 

. reg_f ile_sel (reg_f ile__sel) , 
.polarity (polarity) , 

. zero (zero) 



endmodule 



Named port connection advantages 

named port An advantage of named port connections is that they reduce the risk 
connections are of an inadvertent design error because a net was connected to the 
a preferred style wrong port. In addition, the named port connections better docu- 
ment the intent of the design. In the example above, it is very obvi- 
ous which signal is intended to be connected to which port of the 
flip-flop, without having to go look at the source code of each mod- 
ule. Many companies have internal modeling guidelines that 
require using the named port connection style in netlists, because of 
these advantages. 



Named port connection disadvantages 

named port The disadvantage of the named port connection style is that it is 
connections are very verbose. Netlists can contain tens or hundreds of module 
verbose instances, and each instance can have dozens of ports. Both the 
name of the port and the name of the net connected to the port must 
be listed for each and every port connection in the netlist. Port and 
net names can be up to 1024 characters long in most Verilog tools. 
The IEEE Verilog standard states that tools should support a mini- 
mum of 1024 characters, but can support longer names. When long, 
descriptive port names and net names are used, and there are many 
ports for each module name, the size and verbosity of a netlist using 
named port connections can become excessively large and difficult 
to maintain. 
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8.4.1 Implicit .name port connections 

.name is an SystemVerilog provides three enhancements that greatly simplify 
abbreviation of netlists: .name (pronounced “dot-name”) port connections, .* 
named port (pronounced “dot-star”) port connections, and interfaces. The 
connections name and . * styles are discussed in the following subsections, 
and interfaces are presented in Chapter 9. 

.name simplifies The SystemVerilog .name port connection syntax combines the 
connections to advantages of both the conciseness of ordered port connections 
moduie with self-documenting code and order independence of named-port 
instances connections, eliminating the disadvantages of each of the two Ver- 
ilog styles. In many Verilog netlists, it is common to use the same 
name for both the port name and the name of the net connected to 
the port. For example, the module might have a port called data, 
and the interconnected net is also called data. 



.name infers a Using Verilog’s named port connection style, it is necessary to 
connection of a repeat the name twice in order to connect the net to the port, for 
net and port of example: . data (data) . SystemVerilog simplifies the named port 
the same name connection syntax by allowing just the port name to be specified. 

When only the port name is given, SystemVerilog infers that a net 
or variable of the same name will automatically be connected to the 
port. This means the verbose Verilog style of . data (data) can be 
reduced to simply . data. 



.name can be 
combined with 
named port 
connections 



When the name of a net does not match the port to which it is to be 
connected, the Verilog named port connection is used to explicitly 
connect the net to the port. As with the Verilog named port connec- 
tions, an unconnected port can be left either unspecified, or explic- 
itly named with an empty parentheses set to show that there is no 
connection. 



Example 8-4 lists the simple processor model shown previously in 
example 8-3, but with System Verilog’s .name port connection 
style for all nets that are the same name as the port. Compare this 
example to example 8-3, to see how the . name syntax reduces the 
verbosity of named port connections. Using the . name connection 
style, the netlist is easier to read and to maintain. 
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Example 8-4: Simple netlist using SystemVerilog’s .name port connections 



module miniPIC ( 



inout 


wire 


inout 


wire 


inout 


wire 


input 


wire 


input 


wire 



[7:0] port_a_j?ins, 
[7:0] port__b_pins, 
[7:0] port_c_pins, 
elk, 
resetN 



wire 

wire 

wire 



wire 

wire 

wire 

wire 



[11:0] instructor eg, program_data; 

[10:0] program_counter , program_address ; 

[ 7:0] tmr0_reg, status_reg, fsr_reg, w_reg, option_reg, 
reg__f ile_out, port_a, port^b, port_c, trisa, 
trisb, trisc, data_bus, alu_a, alu_Jb; 

[ 6:0] r eg_f i 1 e__addr ; 

[ 3:0] alu__opcode; 

[ 1:0] alu_aoSel, alu_b_sel; 

reg_f ile_sel, specialoreg_j3el , reg__f ile_enable, 
Woreg__enable, zero_enable, carry_enable, skip, 
isoption, istris, polarity, carry, zero; 



pc_stack pcs ( // module instance with .name port connections 

. program_counter , 

. program_address , 

.elk, 

.resetN, 

. instruct__reg, 

.data__bus, 

. status__reg 

) ; 

prom prom ( 

.dout (programodata) , 

.elk, 

. address (program_address) 

>; 



instruct ion__decode decoder ( 
.alu__opcode, 

,alu_a_sel, 

.alu_b_sel, 

. w_reg_enable , 

.reg_f ile__sel, 

. zero^enable, 

. carry_enable, 

.polarity, 
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. option (isopt ion) , 
. tris (istris) , 

. instruct_reg 



register_f iles regs ( 
.dout (reg_f ile__out) , 

. tmr0_reg, 

. status__reg, 

. fsr_reg, 

.port_a, 

.port_b, 

.port_c, 

. trisa, 

. trisb, 

. trisc, 

.option_reg, 

. w__reg , 

. instructor eg, 

. program_data , 

.port_a_pins, 

. data_bus , 

.address (reg_f ile__addr) , 
.elk, 

. resetN, 

. skip, 

• reg_f ile_sel, 

. zero__enable, 
.carry_enable, 

. w_reg_enable # 

. reg__f ile_enable , 

. zero, 

.carry, 

. special__reg_sel , 

. isopt ion, 

.istris 



alu alu ( 

.y (data_bus) , 

.carry__out (carry) , 

. zero_out (zero) , 

.a (alu_a) , 

.b (alu_b) , 

.opcode (alu_opcode) # 
.carry_in(status_reg [0] ) 

); 
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glue_logic glue ( 
.port_bjpins, 
,port__c_pins, 

. alu__a, 

.alu_b, 

. r eg_f i 1 e_addr , 

. r eg_f i 1 e_enab 1 e , 
. special__reg_sel , 
. skip, 

. instruct__reg, 

. program_counter , 
.port_a, 

.port_b, 

. port_c , 
.data_bus, 

. fsrjreg, 

. tmr0_reg, 

. status_reg, 

. w_reg , 

• re 9_f ile_out , 

. alu__a_sel , 

. alu_b_sel , 

.reg_file_sel, 

.polarity, 

. zero 

) ; 

endmodule 



.name In order to infer a connection to a named port, the net or variable 
connection must match both the port name and the port vector size. In addition, 
inference rutes the data types on each side of the port must be compatible. Incom- 
patible data types are any port connections that would result in a 
warning or error if a net or variable is explicitly connected to the 
port. The rules for what connections will result in errors or warn- 
ings are defined in the IEEE 1364-2001 Verilog standard, in section 
12.3. 10 1 . For example, a tril pullup net connected to a trio pull- 
down net through a module port will result in a warning, per the 
Verilog standard. Such a connection will not be inferred by 
the . name syntax. 



1. IEEE Std 1364-2001, Language Reference Manual (LRM). See page xxvii of this book for 
details. 
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These restrictions reduce the risk of unintentional connections 
being inferred by the .name connection style. Any mismatch in 
vector sizes and/or data types can still be forced, using the full 
named port connection style, if that is the intent of the designer. 
Such mismatches must be explicitly specified, however. They will 
not be inferred from the . name syntax. 



8.4.2 Implicit •* port connection 

.* infers SystemVerilog provides an additional short cut to simplify the 
connections of specification of large netlists. The . * syntax indicates that all 
all nets and ports and nets (or variables) of the same name should automatically 
ports of the be connected together for that module instance. As with the . name 
same name S y n t ax> f or a connection to be inferred, the name and vector size 
must match exactly, and the data types connected together must be 
compatible. Any connections that cannot be inferred by . * must 
be explicitly connected together, using Verilog’s named port con- 
nection syntax. 

Example 8-5 illustrates the use of System Verilog’s . * port con- 
nection syntax. 



Example 8-5: Simple netlist using SystemVerilog’s .* port connections 

module miniPIC ( 

inout wire [7:0] port__a_j?ins , 
inout wire [7:0] port__b_pins , 
inout wire [7:0] port_c_pins, 
input wire elk, 

input wire resetN 

) ; 



wire 

wire 

wire 



wire 

wire 

wire 

wire 



[11:0] instruct_reg, program__data; 

[10:0] program_counter, program__address; 

[ 7:0] tmr0_reg, status__reg, fsr_reg, w_reg, option_reg, 
reg__f ile_out, port_a, port_b, port_c, trisa, 
trisb, trisc, data__bus, alu__a, alu_b; 

[ 6:0] reg_f i le__addr ; 

[ 3:0] alu__opcode; 

[ 1:0] alu__a_sel, alu__b_sel; 

reg_f ile^sel, special_reg_sel, reg__f ile__enable, 
w_reg_ enable, zero__enable, carry__enable, skip, 
isoption, istris, polarity, carry, zero; 
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pc_stack pcs ( // module instance with . * port connections 

. * 

); - 

prom prom ( 

* 

• / 

.dout (program_data) , 

.address (program_address) 



instruct ion_decode decoder ( 
★ 

• / 

.option (isoption) , 

. tris (istris) 

) ; 

register__f iles regs ( 

★ 

• / 

.dout (reg_f ile_out) , 
.address (reg_f ile_addr) 

) ; 

alu alu ( 

.y (data_bus) , 

. carryjout (carry) , 

. zero__out (zero) , 

. a (alu_a) , 

.b (alu__b) , 

.opcode (a lu_opcode) , 

. carry_in (status_reg [0] ) 

) ; 

glue_logic glue ( 

. * 

) ; 



endmodule 




SystemVerilog adds two new types of hierarchy blocks that can 
also have ports, interfaces (see Chapter 9), and programs (refer 
to the forthcoming companion book, SystemVerilog for 
Verification). Instances of these new blocks can also use 
the . name and . * inferred port connections. SystemVerilog 
also allows calls to functions and tasks to use named 
connections, including the . name and . * shortcuts. This is 
covered in section 5.3.6 on page 123. 
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8,5 Net aliasing 



SystemVerilog adds an alias statement that allows two different 
names to reference the same net. For example: 

wire clock; 
wire elk; 

alias elk = clock; 

The net elk is an alias for clock, and clock is an alias for elk. 
Both names refer to the same logical net. 

Defining an alias for a net does not copy the value of one net to 
some other net. In the preceding example, elk is not a copy of 
clock. Rather, elk is clock, just referenced by a different name. 
Any value changes on clock will be seen by elk, since they are 
the same net. Conversely, any value changes made to elk will be 
seen by clock, since they are the same net. 

alias versus assign 

an alias is not The alias statement is not the same as the assign continuous 
an assignment assignment. An assign statement continuously copies an expres- 
sion on the right-hand side of the assignment to a net or variable on 
the left-hand side. This is a one-way copy. The net or variable on 
the left-hand side reflects any changes to the expression on the 
right-hand side. But, if the value of the net or variable on the left- 
hand side is changed, the change is not reflected back to the expres- 
sion on the right-hand side. 

changes on any An alias works both ways, instead of one way. Any value 

aliased net changes to the net name on either side of the alias statement will be 

affect all aliased re fi ec ted on the net name on the other side. This is because an alias 
nets 

is effectively one net with two different names. 

Multiple aliases 

Several nets can be aliased together. A change on any of the net 
names will be reflected on all of the nets that are aliased together. 

wire reset, rst, resetN, rstN; 
alias rst = reset; 



an alias creates 
two or more 
names for the 
same net 
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aliases are not 
order dependent 



8.5.1 



only net types 
can be aliased 



only nets of the 
same type can 
be aliased 



only nets of the 
same size can 
be aliased 



alias reset = resetN; 
alias resetN = rstN; 

The previous set of aliases can also be abbreviated to a single state- 
ment containing a series of aliases, as follows: 

alias rst = reset = resetN = rstN; 

The order in which nets are listed in an alias statement does not 
matter. An alias is not an assignment of values, it is a list of net 
names that, in essence, refer to the same object. 

Alias rules 

SystemVerilog imposes several restrictions on what signals can be 
aliased to another name. 

• Only the net data types can be aliased. Variables, structures, user- 
defined types and other data types cannot be aliased. Verilog’s 
net data types are wire, wand, wor, tri, triand, trior, triO, 
tril, and trireg. 

• The aliased data type must be the same net data type as the net to 
which it is aliased. A wire type can be aliased to a wire type, 
and a wand type can be aliased to a wand type. It is an error, how- 
ever, to alias a wire to a wand or any other data type. 

• The aliased net and the net to which it is aliased must be the same 
vector size. Note, however, that bit and part selects of nets can be 
aliased, so long as the vector size of the left-hand side and right- 
hand side of the alias statement are the same. 

The following examples are all legal aliases of one net to another: 

wire [31:0] nl; 
wire [3:0] [7:0] n2; 

alias n2 = nl; // both nl and n2 are 32 bits 



wire [39:0] d_in; 
wire [7:0] crc; 
wire [31:0] data; 

alias data = d_in[31:0]; // 32 bit nets 

alias crc = d_in[39:32]; // 8 bit nets 
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8.5.2 Implicit net declarations 

implicit nets can An alias statement can infer net declarations. It is not necessary to 
be inferred from f irs t explicitly declare each of the nets in the alias. Implicit nets are 
an alias i n f erre ^ following the same rules as in Verilog for inferring an 
implicit net when an undeclared identifier is connected to a port of 
a module instance. In brief, these rules are: 

• An undeclared identifier name on either side of an alias statement 
will infer a net data type. 

• The default implicit net type is wire. This can be changed with 
the 'default_nettype compiler directive. 

• If the net name is listed as a port of the containing module, the 
implicit net will be the same vector size as the port. 

• If the net name is not listed in the containing module’s port list, 
then a 1-bit net is inferred. 

The following example infers single bit nets called reset and 
rstN, and 64 bit nets called q and d: 

module register (output [63:0] q, 
input [63:0] d, 
input clock, reset) ; 

wire [63:0] out, in; 

alias in = d; // infers d is a 64 -bit wire 

alias out = q; // infers q is a 64 -bit wire 

alias rstN = reset; // infers 1-bit wires 



8.5.3 Using aliases with .name and .* 

The alias statement enables greater usage of the .name and .* 
shortcuts for modeling netlists. These shortcuts are used to connect 
a module port and net of the same name together, without the ver- 
bosity of Verilog’s named port connection syntax. In the following 
example, however, these shortcuts cannot be folly utilized to con- 
nect the clock signals together, because the port names are not the 
same in each of the modules. 
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Figure 8-1: Diagram of a simple netlist 



address 




Example 8-6: Netlist using SystemVerilog’s .* port connections without aliases 

module chip (input wire master_clock, 
input wire master_reset, 

. . . ) ; 

wire [31:0] addr e s s , new__addr e s s , next_addre s s ; 

. *, // infers .address (address) 

.data (new__addr ess) , 

. elk (master_clock) ) ; 

// infers .next__address (next_address) 
. jump__address (new__address) , 

. clock (master_clock) , 

. reset__n (master__reset) ) ; 

. //no connections can be inferred 
.next_addr (next_address) , 

. current__addr (address) , 

.clk(master_clock) , 

. rstN(master__reset) ); 

endmodule 

module ROM (output wire [31:0] data, 

input wire [31:0] address, 

input wire elk) ; 

endmodule 



ROM il ( 



program_count i2 ( 



address_reg i3 ( 
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module program_count (output logic [31:0] next_address, 

input wire [31:0] jump_address, 

input wire clock, reset_n) ; 



endmodule 

module address_reg (output wire [31:0] current_addr , 

input wire [31:0] next_addr, 

input wire elk, rstN) ; 



endmodule 



The master_clock in chip should be connected to all three mod- 
ules in the netlist. However, the clock input ports in the modules are 
not called master_clock. In order for the master_clock net in 
the top-level chip module to be connected to the clock ports of the 
other modules, all of the different clock port names must be aliased 
to master__clock. Similar aliases can be used to connect all reset 
ports to the master__reset net, and to connect other ports together 
that do not have the same name. 

Example 8-7 adds these alias statements, which allow the netlist to 
take full advantage of the .* shortcut to connect all modules 
together. In this example, wires for the vectors are explicitly 
declared, and wires for the different clock and reset names are 
implicitly declared from the alias statement. 

Example 8-7: Netlist using SystemVerilog’s .* connections along with net aliases 

module chip (input wire master_clock, 
input wire master_reset , 

. . . ) ; 

wire [31:0] address, data, new_address, jump_address, 
next_address , next_addr , current_addr ; 

alias elk = clock = master__clock; 
alias rstN = reset_n = master__reset ; 
alias data = new_address = jump_address; 
alias next_address = next_addr; 
alias current_addr = address; 

ROM il ( . * ) ; 

program_count i2 ( . * ) ; 



using aliases 
can simplify 
netlists 
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address_ 


reg i3 


( .* ); 








endmodule 












module ROM 


(output wire [31: 


0] 


data, 






Input 


wire [31: 


0] 


address, 






Input 


wire 




Clk) ; 




endmodule 












module program_count (output 


logic [31:0] 


next_address, 






input 


wire [31:0] 


new__count , 






input 


wire 


clock, reset_n) ; 


endmodule 












module address_reg 


(output wire 


[31:0] address, 






input wire 


[31:0] next__address, 






input wire 


elk, rstN) ; 


endmodule 













In this example, the . * shortcuts infer the following connections to 
the module ports of the module instances: 

ROM il ( .data (data) , 

.address (address) 

.elk (elk) ) ; 

program_count i2 ( .next__address (next__address) , 

. jump_address ( jump_address) , 
.clock (clock) , 

. reset_n (reset_n) ); 

address_reg i3 ( . current_addr (current_addr) , 
.next_addr (next__addr) , 
.clk(clk) , 

.rstN(rstN) ); 

Even though different net names are connected to different module 
instances, such as elk to the ROM module and clock to the 
program_count module, the alias statements make them the same 
net, and make those nets the same as master_clock. 
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8,6 Passing values through module ports 

Verilog The Verilog language places a number of restrictions on what types 
restrictions on of values can be passed through the ports of a module. These 
module ports restrictions affect both the definition of the module and any 
instances of the module. The following bullets give a brief sum- 
mary of the Verilog restrictions on module ports: 

• Only net data types, such as the wire type, can be used on the 
receiving side of the port. It is illegal to connect any type of vari- 
able, such as reg or integer types, to the receiving side of a 
module port. 

• Only net, reg, and integer data types, or a literal integer value 
can be used on the transmitting side of the port. 

• It is illegal to pass the real data type through module ports with- 
out first converting it to a vector using the $realtobits system 
function, and then converting it back to a real number, after pass- 
ing through the port with the $bitstoreal system function. 

• It is illegal to pass unpacked arrays of any number of dimensions 
through module ports. 



8.6.1 All data types can be passed through ports 

SystemVerilog SystemVerilog removes nearly all restrictions on the types of val- 
removes most ues that can be passed through module ports. With SystemVerilog: 
port restrictions 

• Values of any data type can be used on both the receiving and 
transmitting sides of module ports, including real values. 

• Packed and unpacked arrays of any number of dimensions can be 
passed through ports. 

• SystemVerilog structures and unions can be passed through mod- 
ule ports. 




SystemVerilog adds two new types of hierarchy blocks that can 
also have ports, interfaces (see Chapter 9), and programs (refer 
to the forthcoming companion book, System Verilog for 
Verification). These new blocks have the same port connection 
rules as modules. 



The following example illustrates the flexibility of passing values 
through module ports in SystemVerilog. In this example, variables 
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are used on both sides of some ports, a structure is passed through a 
port, and a small memory array, representing a look-up table, is 
passed through a port. 

Example 8-8: Passing values through module ports 

typedef struct packed { 
byte opcode; 
int operand; 
bit carry, zero; 

} instruct ion_t ; 

module decoder (output logic [23:0] microcode, 

input instruction^ instruction, 

input logic [23:0] LUT [255:0] 

) ; 

always ©(instruction) 

microcode = LUT [instruction] ; 

endmodule 

module DSP (input elk, resetN ) ; 

logic [23:0] microcode; 

instruct ion__t instruction; 

logic [23:0] LUT [255:0]; // look-up table 

decoder il ( .microcode, .instruction, .LUT) ; 

initial 

$readmemb ("microcode.dat" , LUT); // load the look-up table 

endmodule 



8.6.2 Module port restrictions in SystemVerilog 

SystemVerilog does place two restrictions on the values that are 
passed through module ports. These restrictions are intuitive, and 
help ensure that the module ports accurately represent the behavior 
of hardware. 
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variables can The first restriction is that a variable data type can only have a sin- 
only be gle source, or driver, of the variable. A driver can be: 
connected to a 

single driver • a module output or inout port 

• a primitive output or inout port 

• a continuous assignment 

• or any number of procedural assignments 

The reason for this single driver restriction is that variables simply 
store the last value written into them. If there were multiple drivers, 
the variable would only reflect the value of the last driver to 
change. Actual hardware behavior is different. In hardware, multi- 
ple drivers are merged together, based on the hardware technology. 
Some technologies merge values based on the strength of the driv- 
ers, some technologies logically-and multiple drivers together, and 
others logically-or multiple drivers together. This implementation 
detail of hardware behavior is represented with Verilog net data 
types, such as wire, wand, and wor. Therefore, SystemVerilog 
requires that a net data type be used when a signal has multiple 
drivers. An error will occur if a variable is connected to two drivers. 

unpacked The second restriction SystemVerilog places on values passed 
values must through module ports is that unpacked data types must be identical 
have matching i n layout on both sides of a module port. SystemVerilog allows 
layouts structures, unions, and arrays to be specified as either packed or 
unpacked (see sections 4.1.3 on page 70, 4.2.2 on page 75, and 
4.3.1 on page 80, respectively). When arrays, structures or unions 
are unpacked, the connections must match exactly on each side of 
the port. 

For unpacked arrays, an exact match on each side of the port is 
when there are the same number of dimensions in the array, each 
dimension is the same size, and each element of the array is the 
same size. 

For unpacked structures and unions, an exact match on each side of 
the port means that each side is declared using the same typedef 
definition. In the following example, the structure connection to the 
output port of the buffer is illegal. Even though the port and the 
connection to it are both declared as structures, and the structures 
have the same declarations within, the two structures are not 
declared from the same user-defined data type, and therefore are an 
exact match. The two structures cannot be connected through a 
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module port. In this same example, however, the structure passed 
through the input port is legal. Both the port and the structure con- 
nected to it are declared using the same user-defined type defini- 
tion. These two structures are exactly the same. 

typede£ struct { // unpacked structure 

int i_data; 
real r_data; 

} data__t; 



module buffer (input data_t in, 

output data__t out) ; 



endmodule 
module chip (...); 

data__t dint; // unpacked structure 

struct { // unpacked structure 

int i_data; 
real r_data; 

} dout; 

buffer il (.in (din), // legal connection 

.out (dout) // illegal connection 

) ; 



endmodule 

Packed and unpacked arrays, structures, and unions are discussed in 
more detail in Chapter 4. 

Packed values are stored as contiguous bits, are analogous to a vec- 
tor of bits, and are passed through module ports as vectors. If the 
array, structure, or union are different sizes on each side of the port, 
Verilog’s standard rules are followed for a mismatch in vector 
sizes. 

Unpacked values allow software tools to add padding between the 
fields that make up the array, structure, or union. This allows a soft- 
ware tool to optimize the storage of information, based on operating 
systems or other criteria. Since the padding between values may 
differ, unpacked values cannot be treated as a simple vector when 
passed through a module port. To ensure portability, SystemVer- 
ilog requires that the layout of unpacked values be identical on both 
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sides of a module port, in order to pass the value through the port. 
An unpacked array must be exactly the same data types on both 
sides of a port. An unpacked structure or union must be exactly the 
same type on both sides of the port. 



8,7 Reference ports 



Verilog modules can have input, output and bidirectional inout 
ports. These port types are used to pass a value of a net or variable 
from one module instance to another. 

a ref port passes SystemVerilog adds a fourth port type, called a ref port. A ref 
a hierarchical port passes a hierarchical reference to a variable through a port, 
reference instead of passing the value of the variable. The name of the port 
through a port becomes an alias to the source variable. Any references to that port 
name directly reference the actual source. 

A reference to a variable of any type can be passed through a ref 
port. This includes all built-in variable types, structures, unions, 
enumerated types, and other user-defined types. To pass a reference 
to a variable through a port, the port direction is declared as ref, 
instead of an input, output, or inout. The data type of a ref 
port must be the same data type as the variable connected to the 
port. 

The following example passes an array into a module, using a ref 
port. 

Example 8-9: Passing an array into a module instance by reference 

typedef struct packed { 
byte opcode; 
int operand; 
bit carry, zero; 

} instruction^ ; 

module decoder (output logic [23:0] microcode, 

input instruction^ instruction, 
ref logic [23:0] TABLE [255:0] 

) ; 



always ©(instruction) 

microcode = TABLE [instruction] ; 
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endmodule 

module DSP (input elk, resetN ) ; 

logic [23:0] microcode; 
instruct ion_t instruction; 

logic [23:0] LUT [255:0]; // Look Up Table 

decoder il ( .*, .TABLE (LUT) ) ; // instance of the decoder 

initial 

$readmemb ( "microcode . dat" , LUT); // load the look-up table 

endmodule 



8.7.1 Reference ports as shared variables 




Passing variables through ports by reference creates shared 
variables, which do not behave like hardware. 



Passing a reference to a variable to another module makes it possi- 
ble for more than one module to write to the same variable. This 
effectively defines a single variable that can be shared by multiple 
modules. That is, procedural blocks in more than one module could 
potentially write values into the same variable. 

It is important to understand that a variable that is written to by 
more than one procedural block does not behave the same as a net 
with multiple sources (drivers). Net data types have resolution 
functionality that continuously merge multiple sources into a single 
value. A wire net, for example, resolves multiple drivers, based on 
strength levels. A wand net resolves multiple drivers by performing 
a bit-wise AND operation. Variables do not have multiple driver 
resolution. Variables simply store the last value deposited. When 
multiple modules share the same variable through ref ports, the 
value of the variable at any given time will be the last value written, 
which could have come from any of the modules that share the vari- 
able. 
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8.7.2 Synthesis guidelines 

Passing references through ports is not synthesizable. 

Passing references to variables through module ports is not synthe- 
sizable. It is recommended that the use of ref ports should be 
reserved for abstract modeling levels where synthesis is not a con- 
sideration. 




8.8 Enhanced port declarations 



8.8.1 Verilog-1995 port declarations 

Verilog-1995 Verilog-1995 required a verbose set of declarations to fully declare 
port declaration a module’s ports. The module statement contains a port list which 
style is verbose defines the names of the ports and the order of the ports. Following 
the module statement, one or more separate statements are required 
to declare the direction of the ports. Following the port direction 
declarations, additional optional statements are required to declare 
the data types of the internal signals represented by the ports. If the 
data types are not specified, the Verilog-1995 syntax infers a net 
data type, which, by default, is the wire data type. This default data 
type can be changed, using the 'default_nettype compiler 
directive. 

module accum (data, result, co, a, b, ci) ; 



inout 


[31:0] 


data; 


output 


[31:0] 


result ; 


output 




CO; 


input 


[31:0] 


a , b; 


input 




ci; 


wire 


[31:0] 


data; 


reg 


[31:0] 


result; 


reg 




CO; 


tril 




ci; 


endmodule 
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8.8.2 VeriIog-2001 port declarations 

Verilog-2001 Verilog-2001 introduced ANSI-C style module port declarations, 
port declaration which allow the port names, port size, port direction, and data type 
style is more declarations to be combined in the port list. 
concise 

module accum (inout wire [31:0] data, 

output reg [31:0] result, 

output reg co , 

input [31:0] a, b, 

input tril ci ) ; 

endmodule 

With the Verilog-2001 port declaration syntax, the port direction is 
followed by an optional data type declaration, and then an optional 
vector size declaration. If the optional data type is not specified, a 
default type is inferred, which is the wire type, unless changed by 
the ' def ault_nettype compiler directive. If the optional vector 
size is not specified, the port defaults to the default width of the 
data type. Following the optional width declaration is a comma- 
separated list of one or more port names. Each port in the list will 
be of the direction, type, and size specified. 

in Verilog, all Verilog-2001’s ANSI-C style port declarations greatly simplify the 
ports must have Verilog- 1995 syntax for module port declarations. There are, how- 
a direction ever, three limitations to the Verilog-2001 port declaration syntax: 
declared 

• All ports must have a direction explicitly declared. 

• The data type cannot be changed for a subsequent port without 
re-specifying the port direction. 

• The vector size of the port cannot be changed for a subsequent 
port without re-specifying the port direction and optional data 
type. 

In the preceding example, the optional data type is specified for all 
but the a and b input ports. These two ports will automatically infer 
the default data type. The optional vector size is specified for the 
data, result, a, and b ports; but not for the co and ci ports. The 
unsized ports will default to the default size of their respective data 
types, which are both 1 bit wide. The vector sizes for result and 
co are different. In order to change the size declaration for co, it is 
necessary to re-specify the port direction and data type of co. Also, 
in the preceding example, input ports a and b do not have a data 



Verilog-2001 
ports have a 
direction, data 
type and size 
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type defined, and therefore default to a wire data type. In order to 
change the data type for the ci input port, the port direction must 
be re-specified, even though it is the same direction as the preced- 
ing ports. 



8.8.3 SystemVerilog port declarations 

SystemVerilog simplifies the declaration of module ports in several 
ways. 

first port defaults First, SystemVerilog specifies a default port direction of inout 
to inout (bidirectional). Therefore, it is no longer required to specify a port 
direction, unless the direction is different than the default. 



subsequent Secondly, if the next port in the port list has a data type defined, but 
ports default to no direction is specified, the direction defaults to the direction of 
direction of the previous port in the list. This allows the data type specification 
previous port to be changed without re-stating the port direction. 

Using SystemVerilog, the Verilog-2001 module declaration for an 
accumulator shown on the previous page can be simplified to: 

module accum (wire [31:0] data, 

output reg [31:0] result, reg co, 
input [31:0] a, b, tril ci ); 



endmodule 

The first port in the list, data, has a data type, but no explicit port 
direction. Therefore, this port defaults to the direction of inout. 
Port co also has a data type, but no port direction. This port defaults 
to the direction of the previous port in the list, which is output. 
Ports a and b have a port direction declared, but no data type. As 
with Verilog-2001 and Verilog-1995, an implicit net data type will 
be inferred, which by default is the type wire. Finally, port ci has 
a data type declared, but no port direction. This port will inherit the 
direction of the previous port in the list, which is input. 




SystemVerilog adds two new types of hierarchy blocks that can 
also have ports, interfaces (see Chapter 9), and programs (refer 
to the forthcoming companion book on SystemVerilog for 
Verification). These new blocks have the same port declaration 
rules as modules. 
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Backward compatibility 

SystemVerilog remains fully backward compatible with Verilog by 
adding a rule that, if the first port has no direction and no data type 
specified, then the Verilog 1995 port list syntax is inferred, and no 
other port in the list can have a direction or data type specified 
within the port list. 

module accum (data, result, ...); 

// Verilog-1995 style because first port has 
// no direction and no data type 



module accum (data, wire [31:0] result, ...); 
// ERROR: cannot mix Verilog-1995 style with 
// Verilog-2001 or SystemVerilog style 



8.9 Parameterized data types 



parameterized Verilog provides the ability to define parameter and 
modules localparam constants, and then use those constants to calculate 
the vector widths of module ports or other declarations. A parame- 
ter is a run-time constant, that can be redefined at elaboration time 
for each instance of a module. Modules that can be redefined using 
parameters are often referred to as parameterized modules. 

polymorphic SystemVerilog adds a significant extension to the concept of rede- 
modules using finable, parameterized modules. With SystemVerilog the data types 
parameterized 0 f a module can be parameterized. Parameterized data types are 
data types declared using the parameter type pair of keywords. 

As with other parameters, parameterized data types can be rede- 
fined for each instance of a module. This capability introduces an 
additional level of polymorphism to Verilog models. With Verilog, 
parameter redefinition can be used to change vector sizes and other 
constant characteristics for each instance of a model. With System- 
Verilog, the behavior of a module can be changed based on the data 
types of a module instance. 

Parameterized data types are synthpsizable, provided the default or 
redefined data types are synthesizable types. 
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In the following example, the data type used by an adder is parame- 
terized. By default, the data type is shortint. Module big_chip 
contains three instances of the adder. Instance ii uses the adder’s 
default data type, making it a 16-bit signed adder. Instance i2 rede- 
fines the data type to int, making this instance a 32-bit signed 
adder. Instance i3 redefines the data type to int unsigned, 
which makes this third instance a 32-bit unsigned adder. 

Example 8-10: Polymorphic adder using parameterized data types 

module adder # (parameter type ADDERTYPE = shortint) 

(input ADDERTYPE a, b, // uses redefinable 

output ADDERTYPE sum, // data types 

output bit carry) ; 

ADDERTYPE temp; // local variable with redefinable type 

always @(a, b) 
temp = a + b; 

assign sum = temp; 

endmodule 

module big_chip ( ... ) ; 



shortint 


a, b, 


rl; 


int 


c , d , 


r2; 


int unsigned 


e, f, 


r3; 



adder il (a, b, rl) ; // 16-bit 

adder #( .ADDERTYPE (int) ) i2 (c, d, r2) ; // 32-bit signed adder 

adder # ( . ADDERTYPE ( int unsigned)) i3 (e, f, r3) ; // unsigned 

// adder 

endmodule 



8.10 Variable declarations in blocks 



local variables in Verilog allows local variables to be declared in named begin...end 
named blocks or Cork... join blocks. A common usage of local variable declara- 
tions is to declare a temporary variable for controlling a loop. The 
local variable prevents the inadvertent access to a variable at the 
module level of the same name, but with a different usage. The fol- 
lowing code fragment has declarations for two variables, both 
named i. The for loop in the named begin block will use the local 
variable i that is declared in that named block, and not touch the 
variable named i declared at the module level. 
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module chip (input clock) ; 

integer i; // declaration at module level 

always @(posedge clock) 

begin: loop // named block 

integer i; // local variable 

for ( i = 0 ; i<=127 ; i=i+l) begin 

end 

end 

endmodule 

hierarchical A variable declared in a named block can be referenced with a hier- 
references to archical path name that includes the name of the block. Typically, 
local variables only a testbench or other verification routine would reference a 
variable using a hierarchical path. Hierarchical references are not 
synthesizable, and do not represent hardware behavior. The hierar- 
chy path to the variable within the named block can also be used by 
VCD (Value Change Dump) files, proprietary waveform displays, 
or other debug tools, in order to reference the locally declared vari- 
able. The following testbench fragment uses hierarchy paths to 
print the value of both the variables named i in the preceding exam- 
ple: 

module test; 

reg clock; 

chip chip (. clock (clock) ) ; 

always #5 clock = -clock; 

initial begin 

clock = 0; 

repeat (5) @(negedge clock) ; 
$display( M chip.i = %0d", chip.i); 

$display ("chip. loop. i = %0d" # chip . loop . i) ; 
$f inish; 

end 

endmodule 



8.10.1 Local variables in unnamed blocks 

local variables in SystemVerilog extends Verilog to allow local variables to be 
unnamed blocks declared in unnamed blocks. The syntax is identical to declarations 
in named blocks, as illustrated below: 
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module chip (input clock) ; 

integer i; // declaration at module level 

always @(posedge clock) 

begin // unnamed block 

integer i; // local variable 

for (i=0; i<=127; i=i+l) begin 

end 

end 

endmodule 



Hierarchal references to variables in unnamed blocks 



local variables in 
unnamed blocks 
have no 
hierarchy path 



Since there is no name to the block, local variables in an unnamed 
block cannot be referenced hierarchically. A testbench or a VCD 
file cannot reference the local variable, because there is no hierar- 
chy path to the variable. 



named blocks Declaring variables in unnamed blocks can serve as a means of pro- 
protect local tecting the local variables from external, cross-module references. 
variables Without a hierarchy path, the local variable cannot be referenced 
from anywhere outside of the local scope. 



inferred This extension of allowing a variable to be declared in an unnamed 
hierarchy paths scope is not unique to SystemVerilog. The Verilog language has a 
fro debugging similar situation. User-defined primitives (UDPs) can have a vari- 
able declared internally, but the Verilog language does not require 
that an instance name be assigned to primitive instances. This also 
creates a variable in an unnamed scope. Software tools will infer an 
instance name in this situation, in order to allow the variable within 
the UDP to be referenced in the tool’s debug utilities. Software 
tools may also assign an inferred name to an unnamed block, in 
order to allow the tool’s waveform display or debug utilities to ref- 
erence the local variables in that unnamed block. The SystemVer- 
ilog standard neither requires nor prohibits a tool inferring a scope 
name for unnamed blocks, just as the Verilog standard neither 
requires nor prohibits the inference of instance names for unnamed 
primitive instances. 



Section 6.6 on page 153 also discusses named blocks; and section 
6.7 on page 156 introduces statement names, which can also be 
used to provide a scope name for local variables. 
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8.11 Summary 



This chapter has presented a number of important extensions to the 
Verilog language that allow modeling the very large netlists that 
occur in multi-million gate designs. Constructs such as . name and 
. * port connections reduce the verbosity and redundancy in 
netlists. net aliasing, simplified port declarations, port connections 
by reference, and relaxed rules on the types of values that can be 
passed through ports all make representing complex design hierar- 
chy easier to model and maintain. 

The next chapter presents SystemVerilog interfaces, which is 
another powerful construct for simplifying large netlists. 




Chapter 9 

System Verilog Interfaces 



OystemVerilog extends the Verilog language with a powerful 
O interface construct. Interfaces offer a new paradigm for model- 
ing abstraction. The use of interfaces can simplify the task of mod- 
eling and verifying large, complex designs. 

This chapter contains a number of small examples, each one show- 
ing specific features of interfaces. These examples have been pur- 
posely kept relatively small and simple, in order to focus on 
specific features of interfaces. Chapter 10 then presents a larger 
example that uses interfaces in the context of a more complete 
design. 



The concepts covered in this chapter are: 

• Interface declarations 

• Connecting interfaces to module ports 

• Differences between interfaces and modules 

• Interface ports and directions 

• Tasks and functions in interfaces 

• Using interface methods 

• Procedural blocks in interfaces 

• Parameterized interfaces 
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9.1 Interface concepts 



The Verilog language connects modules together through module 
ports. This is a detailed method of representing the connections 
between blocks of a design that maps directly to the physical con- 
nections that will be in the actual hardware. For large designs, how- 
ever, using module ports to connect blocks of a design together can 
become tedious and redundant. Consider the following example 
that connects five blocks of a design together using a rudimentary 
bus architecture called main_bus, plus some additional connec- 
tions between some of the design blocks. Figure 9-1 shows the 
block diagram for this simple design, and example 9-1 lists the Ver- 
ilog source code for the module declarations involved. 



Figure 9- 1 : Block diagram of a simple design 




Example 9-1 : Verilog module interconnections for a simple design 



/********************** Top-level Netlist ********************/ 
module top (input wire clock, resetN, test_mode) ; 

wire [15:0] data, address, program_address, jump_address; 
wire [ 7:0] instruction, next_instruction; 
wire [ 3:0] slave_instruction; 



wire 


slave_request , slave_ready; 


wire 


bus_request , bus_grant ; 


wire 


mem_r ead , mem_wr ite; 


wire 


da t already; 
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processor prod ( 

// main_bus ports 
.data (data) , 

.address (address) , 

. s lave_ins truct ion (slave_inst ruction) , 
. slave_request (slave_request) , 
.bus_grant (bus_grant) , 

.mem_read (mem_read) , 

.mem_write (mem_write) , 

.bus_request (bus_request) , 

. slave__ready (slave_ready) , 

// other ports “ 

. j ump_addr e s s ( j ump_addr e s s ) , 

. instruction (instruction) , 

. clock (clock) , 

. resetN(resetN) , 

. test_mode (test_mode) 

) ; 

slave slavel ( 

// main_bus ports — 

.data (data) , 

.address (address) , 

.bus_request (bus__request) , 

. slave_ready (slave_ready) , 

.mem_read (mem_read) , 

.mem__write (mem_write) , 

. slave__inst ruction (slave__inst ruction) , 

. slave__request (slave_request ) , 
.bus__grant (bus_grant) , 

.data_ready (data_ready) , 

// other ports 
. clock (clock) , 

. resetN(resetN) 

) ; 

dual_port_ram ram ( 

// main_bus ports 
.data (data) , 

. dat already (data_ready) , 

.address (address) , 

. mem_read (mem__read) , 

.mem_write (mem_write) , 

// other ports 

.program_address (progratn_address) , 

. data_b (next_inst ruction) 

); 



signals for main bus must 
be individually connected 
to each module instance 
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test__generator test_gen ( 
// main_bus ports 
.data (data) , 

.address (address) , 
.mem_read (mem_read) , 
.mem_write (mem__write) , 

// other ports 
.clock (clock) , 

. resetN(resetN) , 

.test mode (test mode) 



instruction_reg ir ( 

.program^ address (program__address) , 

. instruction (instruction) , 

. jump__address ( jump_address) , 

. next_inst ruction (next__instruction) , 
.clock (clock) , 

.resetN(resetN) 

) ; 

endmodule 



module processor ( 

// main_bus ports 
inout wire [15:0] 
output reg [15:0] 
output reg [ 3:0] 
output reg 
output reg 
output wire 
output wire 
input wire 
input wire 
// other ports 
output reg [15:0] 
input wire [ 7:0] 
input wire 
input wire 
input wire 



Module Definitions 



data, 

address, 

s 1 ave_ins t rue t i on , 

slave_request , 

bus_grant , 

mem_read, 

mem_write, 

bus_request, 

slave_ready, 

jump_address, 
instruction, 
clock, 
resetN, 
test mode 



) ; 



. . . // module functionality code 



endmodule 



********************/ 



ports for main_bus must 
be individually declared in 
each module definition 
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module slave ( 



// mainjbus 


ports 


inout 


wire 


[15:0] 


inout 


wire 


[15:0] 


output 


reg 




output 


reg 




output wire 
output wire 




input 


wire 


[ 3:0] 


input 


wire 




input 


wire 




input 


wire 




// other ports 


input 


wire 




input 


wire 





data, 
address, 
bus_request , 
slave_ready, 
mem_read , 
mernjvrite, 
slave_inst ruction, 
slave__request , 
bus__grant , 
da t already, 

clock, 

resetN 



. . . // module functionality code 



endmodule 



module dual_port_ram ( 
// main_bus ports 
inout wire [15:0] 
output wire 
input wire [15:0] 
input triO 
input triO 
// other ports 
input wire [15:0] 
output reg [ 7:0] 



data, 

da t already, 
address, 
mem__read, 
mem_write, 

program_address , 
data b 



... // module functionality code 

endmodule 



module test_generator 
// main_bus ports 
output wire [15:0] 
output reg [15:0] 
output reg 
output reg 
// other ports 
input wire 
input wire 
input wire 



data, 

address, 

mem__read, 

mem_write, 

clock, 
resetN, 
test mode 



) ; 

... // module functionality code 

endmodule 
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module instruct ion_reg ( 

output reg [15:0] program_address, 
output reg [ 7:0] instruction, 

input wire [15:0] jump_address , 

input wire [ 7:0] next_inst ruction, 
input wire clock, 

input wire resetN 

>; 

// module functionality code 

endmodule 



9.1.1 Disadvantages of Verilog’s module ports 

Verilog’s module ports provide a simple and intuitive way of 
describing the interconnections between the blocks of a design. In 
large, complex designs, however, Verilog’s module ports have sev- 
eral shortcomings. Some of these are: 

• Declarations must be duplicated in multiple modules. 

• Communication protocols must be duplicated in several modules. 

• There is a risk of mismatched declarations in different modules. 

• A change in the design specification can require modifications in 
multiple modules. 

connecting One disadvantage of using Verilog’s module ports to connect major 
modules in a blocks of a design together is readily apparent in the example code 
nettist requires a b ove xhe signals that make up main_bus in the preceding exam- 

declarations P* e must declared in each module that uses the bus, as well as in 
the top-level netlist that connects the design together. In this simple 
example, there are only a handful of signals in main_bus, so the 
redundant declarations are mostly just an inconvenience. In a large, 
complex design, however, this redundancy becomes much more 
that an inconvenience. A large design could have dozens of mod- 
ules connected to the same bus, with dozens of duplicated declara- 
tions in each module. If the ports of one module should 
inadvertently be declared differently than the rest of the design, a 
functional error can occur that may be difficult to find. 

The replicated port declarations also mean that, should the specifi- 
cation of the bus change during the design process, or in a next gen- 
eration of the design, then each and every module that shares the 
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bus must be changed. All netlists used to connect the modules using 
the bus must also be changed. This wide-spread affect of a change 
is counter to good coding styles. One goal of coding is to structure 
the code in such a way that a small change in one place should not 
require changing other areas of the code. A weakness in the Verilog 
language is that a change to the ports in one module will usually 
require changes in other modules. 

Another disadvantage of Verilog’s module ports is that communi- 
cation protocols must be duplicated in each module that utilize the 
interconnecting signals between modules. If, for example, three 
modules read and write from a shared memory device, then the read 
and write control logic must be duplicated in each of these modules. 

module ports Yet another disadvantage of using module ports to connect the 
inhibit abstract blocks of a design together is that detailed interconnections for the 
top-down design design must be determined very early in the design cycle. This is 
counter to the top-down design paradigm, where models are first 
written at an abstract level without extensive design detail. At an 
abstract level, an interconnecting bus should not require defining 
each and every signal that makes up the bus. Indeed, very early in 
the design specification, all that might be known is that the blocks 
of the design will share certain information. In the block diagram 
shown in Figure 9-1 on page 226, the main_bus is represented as a 
single connection. Using Verilog’s module ports to connect the 
design blocks together, however, does not allow modeling at that 
same level of abstraction. Before any block of the design can be 
modeled, the bus must first be broken down to individual signals. 

9.1.2 Advantages of SystemVerilog interfaces 

an interface is SystemVerilog adds a powerful new port type to Verilog, called an 
an abstract port interface. An interface allows a number of signals to be grouped 
tyP e together and represented as a single port. The declarations of the 
signals that make up the interface are contained in a single location. 
Each module that uses these signals then has as a single port of the 
interface type, instead of many ports with the discrete signals. 

Example 9-2 shows how SystemVerilog’s interfaces can reduce the 
amount of code required to model the simple design shown in Fig- 
ure 9-1. By encapsulating the signals that make up main_bus as an 
interface, the redundant declarations for the these signals within 
each module are eliminated. 



protocols must 
be duplicated in 
each module 
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Example 9-2: SystemVerilog module interconnections using interfaces 



/★a***************** interface Definitions *******************/ 



interface main bus; 



wire [15:0] 

logic [ 7:0] 

logic 

logic 

logic 

logic 

logic 

logic 

logic 

endinterface 



data, address; 
s 1 a ve — ins t ruction ; 
slave_request ; 
bus_grant ; 
bus_request ; 
slave__ready; 
da t already; 
mem_read; 
mem_write; 



signals for main_bus are 
defined in just one place 



/********************** Top “level Netlist ********************/ 
module top (input wire clock, resetN, test_mode) ; 
wire [15:0] program__address, jump_address; 
wire [ 7:0] instruction, next__instruction; 

main_bus bus ( ) ; // instance of an interface 

// (instance name is bus) 

processor prod ( 

// main_bus ports 

.bus (bus), // interface connection 
// other ports 
. j ump_addr e s s ( j ump_addre s s ) , 

. instruction (instruction) , 

.clock (clock) , 

. resetN (resetN) , 

. test_mode (testjmode) 

); 



] 



each module instance has a 
single connection for main_bus 



slave slavel ( 

// main_bus ports 
.bus (bus), // interface connection 
// other ports 
.clock (clock) , 

.resetN (resetN) 

); 



j 



dual_port_ram ram ( 

// mainbus ports 
.bus (bus), // interface connection 
// other ports 

. program_address (program_address ) 



G 
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. data__b (next_inst ruction) 

) ; 



test_generator test__gen ( 

// main_bus ports 

.bus (bus), // interface connection 
// other ports 
. clock (clock) , 

.resetN(resetN) , 

.test mode (test mode) 



instruct ion_reg ir ( 

.program_address (program_address) , 

. instruction (instruction) , 

. j ump_addr e s s ( j ump__addr e s s ) , 
.next__inst ruction (next_instruction) , 
.clock (clock) , 

.resetN(resetN) 

) ; 

endmodule 



! ★★★**★*★****★★**★**★ ★ Module Definitions ******'**************/ 

module processor ( 

// mainbus interface port each modu , e definition has a 

main_bus bus, // interface port single port for main_bus 

// other ports — 1 

output reg [15:0] jump_address , 

input wire [ 7:0] instruction, 

input wire clock, 

input wire resetN, 

input wire test_mode 

) ; 

... // module functionality code 

endmodule 

module slave ( 

// main_bus interface port 
mainjous bus, // interface port 
// other ports — * 

input wire clock, 

input wire resetN 

) ; 

... // module functionality code 

endmodule 
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module dual__port_ram ( 

// main_bus interface port 
main__bus bus, // interface port 
// other ports 

input wire [15:0] program__address, 
output reg [ 7:0] data_b 

>; 

... // module functionality code 

endmodule 



module test_generator ( 

// main_bus interface port 
main_bus bus, // interface port 
// other ports 
input wire clock, 

input wire resetN, 

input wire test_mode 

>; 

... // module functionality code 

endmodule 



module instruction_reg ( 

output reg [15:0] program_address, 
output reg [ 7:0] instruction, 

input wire [15:0] jump__address , 

input wire [ 7:0] next_instruction, 
input wire clock, 

input wire resetN 

) ; 

... // module functionality code 

endmodule 



In example 9-2, above, all the signals that are in common between 
the major blocks of the design have been encapsulated into a single 
location — the interface declaration called main__bus. The top-level 
module and all modules that make up these blocks do not repeti- 
tively declare these common signals. Instead, these modules simply 
use the interface as the connection between them. 

Encapsulating common signals into a single location completely 
removes the redundant declarations of Verilog modules. Indeed, in 
the preceding example, since clock and resetN are also common 
to all modules, these signals could have also been brought into the 
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interface. This further simplification is shown later in this chapter, 
in example 9-3 on page 236. 

9.1.3 SystemVerilog interface contents 

interfaces can SystemVerilog interfaces are far more than just a bundle of wires. 
contain Interfaces can encapsulate the full details of the communication 
functionality between the blocks of a design. Using interfaces: 

• The discrete signal and ports for communication can be defined 
in one location, the interface. 

• Communication protocols can be defined in the interface. 

• Protocol checking and other verification routines can be built 
directly into the interface. 

interfaces With Verilog, the communication details must be duplicated in 

eliminate each module that shares a bus or other communication architecture. 

redundant SystemVerilog allows all the information about a communication 
declarations 

architecture and the usage of the architecture to be defined in a sin- 
gle, common location. An interface can contain data type declara- 
tions, tasks, functions, procedural blocks, program blocks, and 
assertions. SystemVerilog interfaces also allow multiple views of 
the interface to be defined. For example, for each module con- 
nected to the interface, the data_bus signal can be defined to be an 
input, output or bidirectional port. 

All of these capabilities of SystemVerilog interfaces are described 
in more detail in the following sections of this chapter. 

9.1.4 Differences between modules and interfaces 

Interfaces are There are three fundamental differences that make an interface dif- 
not the same as fer from a module. First, an interface cannot contain design hierar- 
modules c hy Unlike a module, an interface cannot contain instances of 
modules or primitives that would create a new level of implementa- 
tion hierarchy. Second, an interface can be used as a module port, 
which is what allows interfaces to represent communication chan- 
nels between modules. It is illegal to use a module in a port list. 
Third, an interface can contain modports, which allow each module 
connected to the interface to see the interface differently. Modports 
are described in detail in section 9.6 on page 243. 
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9.2 Interface declarations 

Syntactically, the definition of an interface is very similar to the 
definition of a module. An interface can have ports, just as a mod- 
ule does. This allows signals that are external to the interface, such 
as a clock or reset line, to be brought into the interface and become 
part of the bundle of signals represented by the interface. Interfaces 
can also contain declarations of any Verilog or SystemVerilog data 
type, including all variable types, all net types and user-defined 
types. 

Example 9-3 shows a definition for an interface called main_bus, 
with three external signals coming into the interface: clock, 
resetN and test_mode. These external signals can now be con- 
nected to each module through the interface, without having to 
explicitly connect the signals to each module. 

Notice in this example how the instance of interface mainjaus has 
the clock, resetN and test_mode signals connected to it, using 
the same syntax as connecting signals to an instance of a module. 

Example 9-3: The interface definition for main_bus, with external inputs 

/a****************** Interface Definitions *******************/ 
interface mainjDus (input wire clock, resetN, test_mode) ; 
wire [15:0] data, address; 
logic [ 7:0] s lave_ins true t ion; 
logic slave_request; 

logic bus_grant ; 

logic bus_request ; 

logic slave_ready; 

logic data_ready; 

logic mem_read; 

logic mem_write; 

endinterface 

/********************** Top-level Netlist ********************/ 
module top (input wire clock, resetN, testjrciode) ; 
wire [15:0] program_address , jump_address ; 
wire [ 7:0] instruction, next__instruction; 

main_bus bus ( // instance of an interface 

.clock (clock) , 

.resetN (resetN) , 

. test_mode ( test__mode) 

) ; 



interfaces are 
defined in a 
similar way as 
modules 
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processor prod ( 

// main_bus ports 

.bus (bus), // interface connection 
// other ports 
. j ump_address ( j ump_address ) , 

. instruction ( instruction) 

) ; 



/*** remainder of netlist and module definitions are not ***/ 
/*** listed — they are the same as in example 9-2. ***/ 



interface 
instances can 
use .name and 
* connections 



The SystemVerilog simplified port connection styles of . name and 
. * can also be used with interface port connections. These con- 
structs are covered in section 8.4 on page 193. The previous exam- 
ples can be made even more concise by combining the use of 
interfaces with the use of . * port connections. This is illustrated in 
example 9-4, which follows. 



Example 9-4: Using interfaces with . * connections to simplify complex netlists 



[ 7:0] 



/★★★★****★*****★***★ interface Definitions *******************/ 
interface main_bus (input wire clock, resetN, test_mode) ; 
wire [15:0] data, address; 

s lave_inst ruction ; 
slave__request ; 
bus_grant ; 
bus_request ; 
slave_ready; 
data_ready; 
mem_read; 
mem write; 



logic 
logic 
logic 
logic 
logic 
logic 
logic 
logic 

endinterface 
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j ********************** Top~lsv6l Nstlist ********************^ 
module top (input wire clock, resetN, test_mode) ; 
wire [15:0] program__address , jump_address; 
wire [ 7:0] instruction, next__instruction; 

main bus bus ( . * ) ; | 



processor prod ( . * ); 
slave slavel ( . * ); 
dual_port_ram ram ( . * ); 
instruct ion_r eg ir ( . * ); 
test_generator test_gen( . * ); 
endmodule 



The .* port connection can 
significantly reduce a netlist (compare 
to netlist in example 9-2 on page 232). 



/*** module definitions are not listed — they are the ***/ 
/*** same as in example 9-2. ***/ 



SystemVerilog In the Verilog version of this simple example, which was listed in 
greatly simplifies example 9-1 on page 226, the top-level netlist, module top, 
netlists re q U j rec j 55 lines 0 f code, excluding blank lines and comments. 
Using SystemVerilog interfaces along with .*, example 9-4, 
above, requires just 10 lines of code, excluding blank lines and 
comments, to model the same connectivity. 

9.2.1 Source code declaration order 

The name of an interface can be referenced in two contexts: in a 
port of a module, and in an instance of the interface. Interfaces can 
be used as module ports without concern for file order dependen- 
cies. Just as with modules, the name of an interface can be refer- 
enced before the source code containing the interface definition has 
been read in by the software tool. This means any module can use 
an interface as a module port, without concern for the order in 
which the source code is compiled. 

9.2.2 Global and local interface definitions 

interfaces can An interface can be defined separately from module definitions, 
be global using the keywords interface and endinterf ace. The name of 
declarations t he interface will be in the global module definition name scope, 
just as with module names. This allows an interface definition to be 
used as a port by any module, anywhere in the design hierarchy. 



an interface 
name can be 
used before its 
definition 
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interfaces can 
be limited to 
specific 
hierarchy 
scopes 



An interface definition can be nested within a module, making the 
name of the interface local to that module. Only the containing 
module can instantiate a locally declared interface. This allows the 
use of an interface to be limited to just one portion of the design 
hierarchy, such as to just within an IP model. 



9,3 Using interfaces as module ports 



With SystemVerilog, a port of a module can be declared as an inter- 
face type, instead of the Verilog input, output or inout port 
types. 



9,3*1 Explicitly named interface ports 



a module port 
can be the name 
of an interface 



A module port can be explicitly declared as a specific type of inter- 
face. This is done by using the name of an interface as the port type. 
The syntax is: 



module <module_name> (<interface_name> <port_name>) ; 



For example: 

interface chip__bus; 
endinterface 



module CACHE (chip_bus pins, // interface port 
input clock) ; 



endmodule 

An explicitly named interface port can only be connected to an 
interface of the same name. An error will occur if any other inter- 
face definition is connected to the port. Explicitly named interface 
ports ensure that a wrong interface can never be inadvertently con- 
nected to the port. Explicitly naming the interface type that can be 
connected to the port also serves to document directly within the 
port declaration exactly how the port is intended to be used. 
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9.3.2 Generic interface ports 

a port can be A generic interface port defines the port type using the keyword 
declared using interface, instead of a using the name of a specific interface 
the interface fyp e j^e syntax is: 
keyword 

module <module_name> (interface <port_name>) ; 

When the module is instantiated, any interface can be connected to 
the generic interface port. This provides flexibility in that the same 
module can be used in multiple ways, with different interfaces con- 
nected to the module. In the following example, module RAM is 
defined with a generic interface port: 

module RAM (interface pins, 

input clock) ; 



endmodule 



9.3.3 Synthesis guidelines 

Both styles of connecting an interface to a module are synthesiz- 
able. 



9.4 Instantiating and connecting interfaces 



interfaces are An instance of an interface is connected to a port of a module 
instantiated the instance using a port connection, just as a discrete net would be 

Sam6 modutes connectec * t0 a P ort a m °dule instance. This requires that both the 
interface and the modules to which it is connected be instantiated. 



The syntax for an interface instance is the same as for a module 
instance. If the definition of the interface has ports, then signals can 
be connected to the interface instance, using either the port order 
connection style or the named port connection style, just as with a 
module instance. 



Interface connection rules 



It is illegal to leave an interface port unconnected. 
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interface ports A module input, output or inout port can be left unconnected 
must be 0 n a module instance. This is not the case for an interface port. A 
connected p 0rt j s d ec i ar ed as an interface, whether generic or explicit, 
must be connected to an interface instance or another interface port. 
An error will occur if an interface port is left unconnected. 

On a module instance, a port that has been declared as an interface 
type must be connected to an interface instance, or another interface 
port that is higher up in the hierarchy. If a port declaration has an 
explicitly named interface type, then it must be connected to an 
interface instance of the identical type. If a port declaration has a 
generic interface type, then it can be connected to an interface 
instance of any type. 

The SystemVerilog .name and . * port connection styles can also 
be used with interface instances, as is illustrated in example 9-4 on 
page 237. These port connection styles are discussed in section 8.4 
on page 193. 



Interfaces connected to interface instances 



the port of an 
interface can 
connect to 
another 
interface 



A port of an interface can also be defined as an interface. This capa- 
bility allows one interface to be connected to another interface. The 
main bus of a design, for example might have one or more sub-bus- 
ses. Both the main bus and its sub-busses can be modeled as inter- 
faces. The sub-bus interfaces can be represented as ports of the 
main interface. 



9.5 Referencing signals within an interface 



signais in an 
interface are 
referenced 
using a relative 
hierarchy path 



Within a module that has an interface port, the signals inside the 
interface can be accessed using a relative hierarchy path name. This 
path name is formed using the syntax: 

<port_name> . <internal__int er facets ignal_name> 



In example 9-3 on page 236, the interface definition for main_bus 
contains declarations for clock and resetN. Module slave has 
an interface port, with the port name of bus. The slave model can 
access the clock variable within the interface by referencing it as 
bus . clock. For example: 
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always ©(posedge bus. clock, negedge bus.resetN) 



Example 9-5 lists the partial source code for module slave. The 
model contains several references to signals within the main_bus 
interface. 

Example 9-5: Referencing signals within an interface 

module slave ( 

// main_bus interface port 
main_bus bus 
// other ports 

) ; 

// internal signals 

logic [15:0] slave_data, slave_address; 
bit [15:0] operand_A, operand_B; 
bit mem_select, read, write; 

assign bus. address = mem_select? slave_address : 'z; 
assign bus. data = bus . slave_ready? slave_data: 'z; 

enum {RESET, START, REQ_DATA, EXECUTE, DONE} State, NextState; 

always__ff @(posedge bus. clock, negedga bus.resetN) begin: FSM 
if ( Ibus.resetN) State <= START; 
else State <= NextState; 

end 

always_comb begin : FSM_decode 
unique case (State) 

START: if ( !bus . slave_request ) begin 

bus .bus_request = 0; 

NextState = State; 

end 

else begin 

operand_A = bus . data ; 
slave_address = bus.address; 
bus .bus_request = 1; 

NextState = REQ_DATA; 

end 

// decode other states 

endcase 

end: FSM__decode 

endmodule 
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Use short names for the names of interface ports. 
TIP 



Since signals within an interface are accessed by prepending the 
interface port name to the signal name, it is convenient to use short 
names for interface port names. This keeps the hierarchy path short 
and easy to read. The names within the interface can be descriptive 
and meaningful, as within any Verilog module. 



9.6 Interface modports 



Interfaces provide a practical and straightforward way to simplify 
connections between modules. However, each module connected to 
an interface may need to see a slightly different view of the connec- 
tions within the interface. For example, to a slave on a bus, an 
interrupt_request signal might be an output from the slave, 
whereas to a processor on the same bus, interrupt__request 
would be an input. 

modports define 
interface 
connections 
from the 
perspective of 
the module 



A modport defines the port direction that the module sees for the 
signals in the interface. Examples of two modport declarations are: 

interface chip_bus (input wire clock, resetN) ; 
logic interrupt_request, grant, ready; 
logic [31:0] address; 
wire [63:0] data; 

modport master (input interrupt__request , 
input address, 
output grant, ready, 
inout data, 
input clock, resetN) ; 



SystemVerilog interfaces provide a means to define different views 
of the interface signals that each module sees on its interface port. 
The definition is made within the interface, using the modport key- 
word. Modport is an abbreviation for module port A modport defi- 
nition describes the module ports that are represented by the 
interface. An interface can have any number of modport defini- 
tions, each describing how one or more other modules view the sig- 
nals within the interface. 
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9.6.1 



the modport can 
be selected in 
the module 
instance 



modport slave (output interrupt_request , 
output address, 
input grant, ready, 
inout data, 
input clock, resetN) ; 

endinterface 

The modport definitions do not contain vector sizes or data types. 
This information is defined as part of the signal data type declara- 
tions in the interface. The modport declaration only defines whether 
the connecting module sees a signal as an input, output, bidirec- 
tional inout, or ref port. 

Specifying which modport view to use 

SystemVerilog provides two methods for specifying which mod- 
port view a module interface port should use: 

• As part of the interface connection to a module instance 

• As part of the module port declaration in the module definition 

Both of these specification styles are synthesizable. 

Selecting the modport in the module instance 

When a module is instantiated and an instance of an interface is 
connected to a module instance port, the specific modport of the 
interface can be specified. The connection to the modport is speci- 
fied as: 

cinterf ace_instance_name> . <modport__name> 

For example: 

chip_bus bus; // instance of an interface 

primary il (bus .master) ; // use master modport 

The following code snippet illustrates connecting two modules 
together with an interface called chip_bus. The module called 
primary is connected to the master view of the interface, and the 
module called secondary is connected to the slave view of the 
same interface: 
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Example 9-6: Selecting the modport to use at the module instance 

interface chip__bus (input wire clock, resetN) ; 
modport master (...); 
modport slave (...); 
endinterface 

module primary (interface pins) ; // generic interface port 

endmodule 

module secondary (chip_bus pins) ; // specific interface port 

endmodule 

module chip (input wire clock, resetN) ; 

chip_bus bus (clock, resetN) ; // instance of an interface 

primary il (bus .master) / // use the master modport view 
secondary i2 (bus. slave); // use the slave modport view 

endmodule 



When the modport to be used is specified in the module instance, 
the module definition can use either a generic interface port type or 
an explicitly named interface port type, as discussed in sections 
9.3.2 on page 240, and 9.3.1 on page 239. The preceding example 
shows a generic interface port definition for primary module, and 
an explicitly named port type for secondary module. 

Selecting the modport in the module port declaration 

the modport can The specific modport of an interface to be used can be specified 
be selected in directly as part of the module port declaration. The modport to be 

the modute connec t e d to the interface is specified as: 
definition 

cinterf ace_name> . <modport_name> 

For example: 

module secondary (chip_bus . slave pins); 

endmodule 




246 



SystemVerilog for Design 



The explicit interface name must be specified in the port type when 
the modport to be used is specified as part of the module definition. 
The instance of the module simply connects an instance of the 
interface to the module port, without specifying the name of a mod- 
port. 

The following code snippet shows a more complete context of 
specifying which modport is to be connected to a module, as part of 
the definition of the module. 

Example 9-7: Selecting the modport to use at the module definition 

interface chip_bus (input wire clock, resetN) ; 
modport master (...); 
modport slave (...); 

endinterface 

module primary (chip__bus .master pins); // use master modport 

endmodule 

module secondary (chip_bus . slave pins); // use slave modport 

endmodule 

module chip (input wire clock, resetN) ; 

chip_bus bus (clock, resetN) ; // instance of an interface 

primary il (bus) ; // will use the master modport view 
secondary i2 (bus) ; // will use the slave modport view 

endmodule 




A modport can be selected in either the module instance or the 
module definition, but not both. 



The modport view that a module is to use can only be specified in 
one place, either on the module instance or as part of the module 
definition. It is an error to select which modport is to be used in 
both places. 
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when no 
modport is used, 
nets are 
bidirectional, 
and variables 
are references 



Connecting to interfaces without specifying a modport 

Even when an interface is defined with modports, modules can still 
be connected to the complete interface, without specifying a spe- 
cific modport. However, the port directions of signals within an 
interface are only defined as part of a modport view. When no mod- 
port is specified as part of the connection to the interface, all nets in 
the interface are assumed to have a bidirectional inout direction, 
and all variables in the interface are assumed to be of type ref. A 
ref port passes values by reference, rather than by copy. This 
allows the module to access the variable in the interface, rather than 
a copy of the variable. Module reference ports are covered in sec- 
tion 8.7 on page 214. 

Synthesis considerations 

Synthesis supports both styles of specifying which modport is to be 
used with a module. The synthesis process will expand the interface 
port of a module into the individual ports represented in the mod- 
port definition. The following code snippets show the pre- and post- 
synthesis module definitions of a module using an interface with 
modports. 



Pre-synthesis model, with an interface port: 

module primary (chip_bus .master pins)/ 

endmodule 

interface chip_bus (input wire clock, resetN) ; 
logic interrupt_request, grant, ready; 
logic [31:0] address; 
wire [63:0] data; 

modport master (input interrupt__request , 
input address, 
output grant, ready, 
inout data, 
input clock, resetN) ; 



endinterface 
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Post-synthesis model: 

module primary (interrupt_request , address, 
grant, ready, data, 
clock, resetN) ; 
input interrupt__request, 
input [31:0] address, 
output grant, ready, 
inout [63:0] data, 
input clock, resetN) ; 

... // synthesized model functionality 
endmodule 

If no modport is specified when the model is synthesized, then all 
signals within the interface become bidirectional inout ports on 
the synthesized module. 

9.6.2 Using modports to define different sets of connections 

In a more complex interface between several different modules, it 
may be that not every module needs to see the same set of signals 
within the interface. Modports make it possible to create a custom- 
ized view of the interface for each module connected. 

Restricting module access to interface signals 

modports limit A module can only directly access the signals listed in its modport 

access to the definition. This makes it possible to have some signals within the 

contents of an interface completely hidden from view to certain modules. For 
interface x 

example, the interface might contain a net called test_clock that 
is only used by modules connected to the interface through the 
master modport, and not by modules connected through the 
slave modport. 

A modport does not prohibit the use of a full hierarchy path to 
access any object in an interface. However, full hierarchy paths are 
not synthesizable, and are primarily used for verification. 

It is also possible to have internal signals within an interface that 
are not visible through any of the modport views. These internal 
signals might be used by protocol checkers or other functionality 
contained within the interface, as discussed later in this chapter. If a 
module is connected to the interface without specifying a modport, 
the module will have access to all signals defined in the interface. 
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Example 9-8 adds modports to the main_bus interface example. 
The processor module, the slave module and the RAM module 
all use different modports within the main_bus interface, and the 
signals within the interface that can be accessed by each of these 
modules are different. The test block is connected to the main_bus 
without specifying a modport, giving the test block complete, unre- 
stricted access to all signals within the interface. 



Example 9-8: A simple design using an interface with modports 



/******************* interface Definitions *******************/ 
interface main__bus (input wire clock, resetN, test_mode) / 
wire [15:0] data, address; 
logic [ 7:0] s lave__inst ruction ; 
logic slave_request; 

logic bus_grant ; 

logic bus__request ; 

logic slave__ready; 

logic data_ready; 

logic mem_read; 

logic mem_write; 



modport master 



modport slave 



(inout data, 
output address, 
output slave_inst ruction, 
output slave__request , 
output bus_grant, 
output mem_read, 
output mem__write, 
input bus_request, 
input slave_ready, 
input data_ready, 
input clock, 
input resetN, 
input test__mode 
) ; 

(inout data, 
inout address, 
output mem_read, 
output mem__write, 
output bus__request, 
output slave__ready, 
input slave_inst ruction, 
input slave_request , 
input bus_grant , 
input data_ready, 
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modport mem 



endinterface 



input clock, 
input resetN 
) ; 

(inout data, 
output data__ready, 
input address, 
input mem_read, 
input mem_wr i t e 
) ; 



/★****************★**** Top-level Net list ********************/ 
module top (input wire clock, resetN, test_mode) ; 
wire [15:0] program_address, jump_address; 
wire [ 7:0] instruction, next_instruction; 

main_bus bus ( . * ); // instance of an interface 

processor prod ( .bus (bus .master) , . * ) ; 
slave slavel ( .bus (bus . slave) ) ; 
dual_j?ort__ram ram ( .bus (bus .mem) , .* ); 
instruct ion_r eg ir ( . * ); 
test_generator test_gen ( .bus (bus) ) ; 
endmodule 

/*** module definitions are not listed — they are the ***/ 

/*** same as in example 9-2 on page 232. *★*/ 



9,7 Using tasks and functions in interfaces 



interfaces can Interfaces can encapsulate the full details of the communication 
contain protocol between modules. For instance, the mainjDus protocol in 
functionality t ^ e p rev i ous example includes handshaking signals between the 
master processor and the slave processor. In regular Verilog, the 
master processor module would need to contain the procedural 
code to assert and de-assert its handshake signals at the appropriate 
time, and to monitor the slave handshake inputs. Conversely, the 
slave processor would need to contain the procedural code to assert 
and de-assert its handshake signals, and to monitor the handshake 
inputs coming from the master processor or the RAM. 
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Describing the bus protocol within each module that uses a bus 
leads to duplicated code. If any change needs to be made to the bus 
protocol, the code for the protocol must be changed in each and 
every module that shares the bus. 

9.7.1 Interface methods 

an interface SystemVerilog allows tasks and functions to be declared within an 

method is a task interface. These tasks and functions are referred to as interface 
or function methods _ 

A task or function that is defined within an interface is written 
using the same syntax as if it had been within a module, and can 
contain the same types of statements as within a module. These 
interface methods can operate on any signals within the interface. 
Values can be passed in to interface methods from outside the inter- 
face as input arguments. Values can be written back from interface 
methods as output arguments or function returns. 

methods Interface methods offer several advantages for modeling large 
encapsulate designs. Using interface methods, the details of communication 
functionality in f rom one mo dule to another can be moved to the interface. The 
p code for communicating between modules does not need to be rep- 
licated in each module. Instead, the code is only written once, as 
interface methods, and shared by each module connected using the 
interface. Within each module, the interface methods are called, 
instead of implementing the communication protocol functionality 
within the module. Thus, an interface can be used not only to 
encapsulate the data connecting modules, but also the communica- 
tion protocols between the modules. 

9.7.2 Importing interface methods 

modules can Interface methods (tasks and functions) can be called from modules 
import interface that are connected to the interface by using the relative hierarchical 
methods name jf the interface is connected via a modport, the method must 
be specified using the import keyword. The import definition is 
specified within the interface, as part of a modport definition. Mod- 
ports specify interface information from the perspective of the 
module. Hence, an import declaration within a modport indicates 
that the module is importing the task or function. 

The import declaration can be used in two ways: 
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• Import using just the task or function name 

• Import using a full prototype of the task or function 

Import using a task or function name 

The simplest form of importing a task or function is to simply spec- 
ify the name of the task or function. The basic syntax is: 

modport ( import <task__function_name> ) ; 

An example of using this style is: 

modport in (import Read, 

import parity_gen, 
input clock, resetN ) ; 

Import using a task or function prototype 

The second style of an import declaration is to specify a full proto- 
type of the task or function arguments. This style requires that the 
keyword task or function follow the import keyword. It also 
requires that the task or function name be followed by a set of 
parentheses, which contain the formal arguments of the task or fun- 
citon. The basic syntax of this style of import declarations is: 

modport ( import task <task__name> (<task_formal_arguments) ); 

modport ( import function <function_name> 

(<function_formal_arguments>) ) ; 



For example: 

modport in (import task Read 

(input [63:0] data, 
output [31:0] address), 
import function parity_gen 

(input [63:0] data), 
input clock, resetN) ; 

A full prototype can serve to document the arguments of the task or 
function directly as part of the modport declaration. The full proto- 
type is only required when the task or function has been exported 
from another module (explained in section 9.7.4 on page 255), or 
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when a function has been externally defined using SystemVerilog’s 
Direct Programming Interface (not covered in this book). 



Calling imported interface methods 

imported Importing a task or function through a modport gives the module 
methods are using the modport access to the interface method. The task or func- 
accessed^with^a t j on j s ca n e( j by prepending the interface port name to the task or 

hierarchy path ^ nc ^ on name > the same as when a signal within an interface is 
accessed. 

<interf ace_j?ort_name> . <method_name> 



Alternate methods within interfaces 

interfaces can Modports provide a way to use different methods and protocols 
contain alternate within the same interface. The interface can contain a variety of dif- 
methods f eren t methods, each using different protocols or data types. 

The following code snippet example illustrates an interface called 
math_bys. Within the interface, different read methods are 
defined, which retrieve either integer data or floating point data 
through an interface. Two modules are defined, called 
integer_math__unit and float ing_j?oint__unit, both of 
which use the same math_bus interface. Each module will access 
different types of information, based on the modport used in the 
instantiation of the module. 

Example 9-9: Using modports to select alternate methods within an interface 



j ***★★★★★********★* * Interface Definitions *******************/ 
interface math_bus (input wire clock, resetN) ; 
int a_int, b_int, result__int; 
real a__real, b_real, result_real; 

task IntegerRead (output int a_int, b_int) ; 

... //do handshaking to fetch a and b values 

endtask 

task FloatingPointRead (output real a_real, b_real) ; 

... // do handshaking to fetch a and b values 

endtask 
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modport 


int__io 


(import 


IntegerRead, 






input 


clock, resetN, 






output ref 


result_int) ; 


modport 


f P_i° 


( import 


Float ingPointRead 






input 


clock, resetN, 






output ref 


result_real) ; 



endinterface 



/********************** Top-level Netlist ********************/ 
module top; 

math__bus bus_a; // 1st instance of the math__bus interface 

math_bus bus_b; // 2nd instance of the math__bus interface 

integer_math_unit il (bus_a . int__io) ; 

// connect to interface using integer data types 

f loating_point_unit i2 (bus_b. fp__io) ; 

// connect to interface using real data types 

endmodule 

/********************* Module Definitions ********************/ 
module integer_math_unit (interface io) ; 

int a_reg , b_reg ; 

always ©(posedge clock) 
begin 

io. IntegerReadfa^reg, b_reg) ; // call method in 

// interface 

... // process math operation 

end 

endmodule 

module f loating_point_unit (interface io) ; 

real a_reg , b_reg ; 

always ©.(posedge clock) 
begin 

io. Float ingPointRead(a_reg, b_reg) ; // call method in 

// interface 

... // process math operation 

end 

endmodule 
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9.7.3 Synthesis guidelines for interface methods 

Modules that use tasks or functions imported from interfaces are 
synthesizable. Synthesis will infer a local copy of the imported task 
or function within the module. The post-synthesis version of the 
module will contain the logic of the task or functions; it will no 
longer look to the interface for that functionality. 




Imported tasks or functions must be declared as automatic 
and not contain static declarations in order to be 
synthesized. 



An automatic task or function allocates new storage each time it is 
called. When a module calls an imported task or function, a new 
copy is allocated. This allows synthesis to treat the task or function 
as if were a local copy within the module. 



9.7.4 Exporting tasks and functions 



modules can SystemVerilog interfaces and modports provide a mechanism to 
export methods define a task or function in one module, and then export the task or 
into an interface function through an interface to other modules. 




Exporting tasks and functions is not synthesizable. 



exported 
methods are not 
synthesizable 



Exporting tasks or functions into an interface is not synthesizable. 
This modeling style should be reserved for abstract models that are 
not intended to be synthesized. 



An export declaration in an interface modport does not require a 
full prototype of the task or function arguments. Only the task or 
function name needs to be listed in the modport declaration. 



An import declaration of an exported task or function must have a 
complete prototype of the task/function arguments. The prototype 
must match the arguments as they are defined in the declaration of 
the task or function. 



The code fragments in example 9-10 show a function called check 
that is declared in module CPU. The function is exported from the 
CPU through the master modport of the chip_bus interface. The 
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same function is imported into any modules that use the slave 
modport of the interface. To any module connected to the slave 
modport, the check function appears to be part of the interface, just 
like any other function imported from an interface. Modules using 
the slave modport do not need to know the actual location of the 
check function definition. 



Example 9-10: Exporting a function from a module through an interface modport 

interface chip_bus (input wire clock, resetN) ; 
bit request, grant, ready; 

logic [63:0] address, data; 

modport master (output request, ... 

export check ) ; 



modport slave 



endinterface 



(input request, . . . 
import check (input bit parity, 

input [63:0] logic data) ); 



module CPU (chip__bus .master io) ; 

function check (input bit parity, input [63:0] logic data); 
endf unction 



endmodule 



Exporting a task or function to the entire interface 

The export declaration allows a module to export a task or func- 
tion to an interface through a specific modport of the interface. A 
task or function can also be exported to an interface without using a 
modport. This is done by declaring an extern prototype of the task 
or function within the interface. For example: 
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Example 9-11: Exporting a function from a module into an interface 

interface chip_bus (input bit clock) ; 
bit request, grant, ready; 

logic [63:0] address, data; 

extern function check (input bit parity, 

input [63:0] logic data); 



modport master (output request, . ..); 

modport slave (input request, . . . 

import function check 

(input bit parity, 
input [63:0] logic data) ); 

endinterface 



module CPU (chip_bus .master io) ; 

function check (input bit parity, input [63:0] logic data); 



endfunction 



endmodule 



Restrictions on exporting tasks and functions 




It is illegal to export the same function name from multiple 
instances of a module. It is legal, however, to export a task name 
from multiple instances, using an extern fork join 
declaration. 



restrictions on SystemVerilog places a restriction on exporting functions through 
exporting interfaces. It is illegal to export the same function name from two 
functions different modules, or two instances of the same module, into the 
same interface. For example, module A and module B cannot both 
export a function called check into the same interface. 



restrictions on SystemVerilog places a restriction on exporting tasks through inter- 
exporting tasks faces. It is illegal to export the same task name from two different 
modules, or two instances of the same module, into the same inter- 
face, unless an extern fork join declaration is used. The multi- 
ple export of a task corresponds to a multiple response to a 
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broadcast. Tasks can execute concurrently, each taking a different 
amount of time to execute statements, and each call returning dif- 
ferent values through its outputs. The concurrent response of mod- 
ules A and B containing a call to a task called taskl is conceptually 
modeled by: 

fork 

<hierarchical_name_of_jnodule_A> . taskl (q, r) ; 
<hierarchical_name__of__module__B> . taskl (q, r) ; 

join 

extern forkjoin Because an interface should not contain the hierarchical names of 
allows multiple the modules to which it is connected, the task is declared as 
instances of extern forkjoin, which infers the behavior of the fork.. .join 
expo e as s j ) j oc j c a b ove if t jj e contains outputs, it is the last instance of the 
task to finish that determines the final output value, just as in the 
fork... join block above. 

This construct can be useful for abstract, non-synthesizable transac- 
tion level models of busses that have slaves, where each slave 
determines its own response to broadcast signals (see example 1 1-2 
on page 297 for an example). The extern forkjoin can also be 
used for configuration purposes, such as counting the number of 
modules connected to an interface. Each module would export the 
same task, name which increments a counter in the interface. 



9,8 Using procedural blocks in interfaces 



interfaces can 
contain protocol 
checkers and 
other 
functionality 

One usage of procedural blocks within interfaces is to facilitate ver- 
ification of a design. One application of using procedural state- 
ments within an interface is to build protocol checkers into the 
interface. Each time modules pass values through the interface, the 
built-in protocol checkers can verify that the design protocols are 
being met. Examples of using procedural code within interfaces are 
presented in the forthcoming companion book, SystemVerilog for 
Verification . 



In addition to methods (tasks and functions), interfaces can contain 
Verilog procedural blocks and continuous assignments. This allows 
an interface to contain functionality that can be described using 
initial, always or final procedural blocks, and assign state- 
ments. An interface can also contain verification program blocks. 
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9.9 Reconfigurable interfaces 



Interfaces can use parameter redefinition and generate statements, 
in the same way as modules. This allows interface models to be 
defined that can be reconfigured each time an interface is instanti- 
ated. 

Parameterized interfaces 

interfaces can Parameters can be used in interfaces to make vector sizes and other 
use parameters, declarations within the interface reconfigurable using Verilog’s 
modu/es P arameter redefinition constructs. SystemVerilog also adds the 
ability to parameterize data types, which is covered in section 2.1 1 
on page 46. 

Example 9-12, below, adds parameters to example 9-9 on page 253 
shown earlier, which uses different modports to pass either integer 
data or real data through the same interface. In this example, the 
data types of the interface are parameterized, so that each instance 
of the interface can be configured to use integer or real data types. 

Example 9-12: Using parameters in an interface 

interface math_bus # (parameter type DTYPE = int) 

(input bit clock) ; 

DTYPE a, b, result; // parameterized data types 

task Read (output DTYPE a, b) ; 

... // do handshaking to fetch a and b values 

endtask 

modport int_io (import Read (output DTYPE a, b) , 

input bit clock, 
output DTYPE result) ; 

modport fp__io (import Read (output DTYPE a, b) , 

input bit clock, 
output int result) ; 

endinterface 
module top; 

math_bus bus__a; // interface uses int data 

math__bus (# .DTYPE (real) ) bus_b; // interface uses real data 

integer_math_unit il (bus_a. int_io) ; 
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// connect to interface using integer data types 

float ing_point_unit i2 (bus_b. fp_io) ; 

// connect to interface using real data types 

endmodule // end of module top 



The preceding example uses the Verilog-2001 style for declaring 
parameters within a module and for parameter redefinition. The 
older Verilog-1995 style of declaring parameters and doing param- 
eter redefinition can also be used with interfaces. 

Using generate blocks 

interfaces can The Verilog-2001 generate statement can also be used to create 
use generate reconfigurable interfaces. Generate blocks can be used to replicate 
blocks con tinuous assignment statements or procedural blocks any number 
of times. 



9.10 Verification with interfaces 



Using only Verilog-style module ports, without interfaces, a typical 
design and verification paradigm is to develop and test each module 
of a design, independent of other modules in the design. After each 
module is independently verified, the modules are connected 
together to test the communication between modules. If there is a 
problem with the communication protocols, it may be necessary to 
make design changes to multiple modules. 

communication 
protocols can be 
verified before a 
design is 
modeled 



Verification of designs that use interfaces is covered in much 
greater detail in the forthcoming companion book, SystemVerilog 
for Verification. 



Interfaces can enable a different paradigm for verification. With 
interfaces, the communication channels can be developed as inter- 
faces independently from other modules. Since an interface can 
contain methods for the communication protocols, the interface can 
be tested and verified independent of the rest of the design. Mod- 
ules that use the interface can be written knowing that the commu- 
nication between modules has already been verified. 
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9.11 Summary 



This chapter has presented one of most powerful additions to the 
Verilog language for modeling very large designs: interfaces. An 
interface encapsulates the communication between major blocks of 
a design. Using interfaces, the detailed and redundant module port 
and netlist declarations are greatly simplified. The details are 
moved to one modeling block, where they are defined once, instead 
of in many different modules. An interface can be defined globally, 
so it can be used by any module anywhere in the design hierarchy. 
An interface can also be defined to be local to one hierarchy scope, 
so that only that scope can use the interface. 

Interfaces do more than provide a way to bundle signals together. 
The interface modport definition provides a simple yet powerful 
way to customize the interface for each module that it is connected 
to. The ability to incorporate methods (tasks and functions) and 
procedural code within an interface make it possible instrument and 
drive the simulation model in one convenient location. 




Chapter 10 

A Complete Design 
Modeled with System Verilog 



r his chapter brings together the many concepts presented in 
previous chapters of this book, and shows how the SystemVer- 
ilog enhancements to Verilog can be used to model large designs 
much more efficiently than with the standard Verilog HDL. The 
example presented in this chapter shows how SystemVerilog can be 
used to model at a much higher level of data abstraction than Ver- 
ilog, and yet be fully synthesizable. 



10,1 SystemVerilog ATM example 



The design used as an example for this chapter is based upon an 
example from Janick Bergeron’s Verification Guild 1 . The original 
example is a non-synthesizable behavioral model written in Verilog 
(using the Verilog- 1995 standard). The example is a description of 
a quad Asynchronous Transfer Mode (ATM) user-to-network inter- 
face and forwarding node. For this book, this example has been 
modified in three significant ways. First, the code has been re-writ- 
ten in order to use many SystemVerilog constructs. Second, the 
non-synthesizable behavioral models have been rewritten using the 
SystemVerilog synthesizable subset. Third, the model has been 
made configurable, so that it can be easily scaled from a 4x4 quad 
switch to a 16x16 switch, or any other desired configuration. 



1 . The Verification Guild is an independent e-mail newsletter and moderated discussion forum 
on hardware verification. Information on the Verification Guild example used as a basis for 
the example in this chapter can be found at www.janick.bergeron.com/guild/project.html. 
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The example in this chapter illustrates how the use of SystemVer- 
ilog structures, unions, and arrays significantly simplifies the repre- 
sentation of complex design data. The use of interfaces and 
interface methods further simplifies the communication of complex 
data between the blocks of a design. 

The SystemVerilog coding style used in this example also shows 
how the design can be automatically sized and configured from a 
single source. Using +def ine invocation options, the architecture 
of the design can be configured as an NxP port forwarding node, 
where N and P can be any positive value. Rather than producing a 
fixed 4x4 design, as was the case in the original Verilog-1995 
example, this SystemVerilog version can produce a 128x128, 
16x128, 128x16, or any other configuration imaginable. The sizing 
and instantiation of the module and data declarations is handled 
implicitly (including the relatively simple testbench used with this 
example). 

The SystemVerilog version presented here has been simulated 
using the Synopsys VCS simulator, and synthesized using the Syn- 
opsys Design Compiler. 



10.2 Data abstraction 



SystemVerilog allows the designer to raise the level of abstraction 
for the data representation. In Verilog, the data type set is rather 
limited in comparison to SystemVerilog. What is needed is a set of 
data types that reflects the nature of the design. 

The two ATM formats used in this ATM design are the uni format 
and the nni format. 
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Figure 10-1: UNI and NNI cell formats 
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NNI Cell Format 



An ATM cell simply consists of 53 bytes of data. This can be mod- 
eled as an array of bytes in Verilog, but the meaning of those bytes 
within the cell is lost when modeled in this manner. Using packed 
structure definitions for the two different formats is easy in System- 
Verilog, and makes each cell member easily identifiable: 



UNI Cell Structure 

typedef struct packed { 



bit 


[ 3:0] 


GFC; 


bit 


[ 7:0] 


VPI; 


bit 


[15:0] 


VC I ; 


bit 




CLP; 


bit 


[ 2:0] 


T; 


bit 


[ 7:0] 


HEC; 


bit [0:47] 


[ 7:0] 


Payload; 



} uniType; 



NNI Cell Structure 



typedef 


struct packed { 


bit 


[11:0] VPI 


bit 


[15:0] VCI 


bit 


CLP 


bit 


[2:0] PT; 


bit 


[7:0] HEC 



bit [0:47] [7:0] Payload; 

} nniType; 
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An important advantage of this level of data abstraction is that the 
53 byte array of data can now be easily treated as though it were 
either of these formats, or as a simple array of bytes. This can be 
done by using a packed union of the two data packet formats: 

Union of UNI / NNI / byte stream 

typedef union packed { 

uniType uni; 
nniType nni; 
bit [0:52] [7:0] Mem; 

} ATMCel lType ; 

When an object is declared of type ATMCel lType, its members can 
be accessed as though it were either a uniType cell, or an nniType 
cell, depending upon which fields need to be accessed. 

A useful extension to this abstract data representation is to use data 
tagging as part of the testbench. For either type of cell (UNI or 
NNI), the last 48 bytes of data are the payload, which is user 
defined. These fields can be used as part of the test procedures, in 
order to carry part of the test data through the switch. In this partic- 
ular example, the payload can be used to record at which input port 
the data arrived, and what was its sequence in all packets arriving at 
that port. This is easily done by defining another structure, that is 
only used by the testbench: 

Test view cell format (payload section) 

typedef struct packed { 

bit [0:4 ] [7:0] Header; 

bit [0:3 ] [7:0] PortID; 

bit [0:3 ] [7:0] PacketID; 

bit [0:39] [7:0] Padding; 

} tstType; 

All 5 bytes of the UNI/NNI header are encapsulated in a single field 
called Header. The fields that are used for the data tagging are the 
PortID and PacketID fields, which form part of the payload for 
the UNI/NNI ATM cells. This third abstract representation of the 
53 bytes of data can be added to the packed union. 
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Union of UNI / NNI / test view / byte stream 

typedef union packed { 

uniType uni; 
nniType nni; 
tstType tst ; 
bit [0:52] [7:0] Mem; 

} ATMCe 1 1 Type ; 

The 53 bytes of data can now be easily configured in four different 
ways: 

• as a UNI cell 

• as an NNI cell 

• as a testbench tagged packet 

• as an array of 53 bytes of data 

Because the array, union, and structures are packed, the mapping of 
the corresponding bits are guaranteed when data is written using 
one format, and read in another format. 



10,3 Interface encapsulation 



The example in this chapter is based on the UTOPIA interface 
specifications from the ATM Forum Technical Committee 1 . This 
interface has been encapsulated in a SystemVerilog interface defi- 
nition called Utopia. This definition contains the signals of the 
interface, an instance of an ATMCe 11 Type (described above), a set 
of modports (indicating dataflow direction), and a nested interface 
called Method, which is an instance of utopiaMethod. 

The nested UtopiaMethod interface contains the testbench trans- 
action level interface routines, and is not synthesizable. By separat- 
ing it from the rest of the interface, it does not clutter the design. 
The instance of this testbench interface can easily be excluded from 
synthesis using synthesis off/on pragmas. 



1. ATM Forum Technical Committee, UTOPIA Specification Level 1, Version 2.01, Document 
af-phy-0017.000, March 21, 1994 (available at ftp://ftp.atmforum.com/pub/approved-specs/ 
af-phy-0017.000.pdf) and ATM Forum Technical Committee, UTOPIA Level 2, Version 
1.0, Document af-phy-0039.000, June 1995 (available at ftp://ftp.atmforum.com/pub/ap- 
proved-specsZaf-phy-0039.000.pdf). 
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Example 10-1: Utopia ATM interface, modeled as a SystemVerilog interface 

interface Utopia; 

parameter int If Width = 8; 

bit clk__in; 
bit clk__out ; 

logic [ I f Width- 1:0] data ; 

bit soc; 

bit en; 

bit clav; 

bit valid; 

bit ready; 

bit reset; 

bit selected; 

ATMCellType ATMcell; // union of structures for ATM cells 
modport TopReceive ( 

input clk_in, data, soc, clav, ready, reset, 
output clk_out, en, ATMcell, valid ) ; 

modport TopTransmit ( 

input clk_ in, clav, ATMcell, valid, reset, 
output clk__out, data, soc, en, ready ) ; 

modport CoreReceive ( 

input clk_in, data, soc, clav, ready, reset, 
output clk__out, en, ATMcell, valid ) ; 

modport CoreTransmit ( 

input clk_in, clav, ATMcell, valid, reset, 
output clk_out, data, soc, en, ready ) ; 

"ifndef SYNTHESIS // synthesis ignores this code 
UtopiaMethod Method; // interface with testing methods 
"endif 

endinterface 



In addition to the utopia interface, there is a management inter- 
face, called CPU, and a look-up table interface, called Lookup - 
Table. The LookupTable interface is used in the core of the 
device called squat, in order to provide a latch-based read/write 
look-up table. The storage data type of this look-up table is defined 
through a type parameter called dType, which means it can be 
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instantiated to store any built-in or user-defined data type (as will 
be shown later). 



Example 10-2: Cell rewriting and forwarding configuration 

typedef struct packed { 

bit PTxPorts-1 : 0] FWD; 
bit [11:0] VPI ; 

} CellCfgType; 



interface CPU; 
logic 

logic [11:0] 
logic 

CellCfgType 

CellCfgType 

logic 

logic 

logic 



BusMode ; 
Addr ; 

Sel; 
Dataln; 
DataOut ; 
Rd_DS ; 
Wr_RW; 
Rdy__Dtack; 



modport Peripheral ( 

input BusMode, Addr, Sel, Dataln, Rd_DS, WrJRW, 
output DataOut, Rdy_Dtack 

) ; 



"ifndef SYNTHESIS // synthesis ignores this code 

CPUMethod Method; // interface with testing methods 
'endif 

endinterface 



interface LookupTable; 

parameter int Asize = 8; 

parameter int Arange = l<<Asize; 

parameter type dType = bit; 

dType Mem [0 : Arange -1] ; 

// Function to perform write 

function void write (input [Asize-1:0] addr, 

input dType data ) ; 

Mem [addr] = data; 

endfunction 

// Function to perform read 

function dType read (input bit [Asize-1:0] addr) ; 

return (Mem [addr]); 
endfunction 
endinterface 
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All the above definitions are contained in a file called defini- 
tions . sv, which is guarded as follows: 

"ifndef _INCL_DEFINITIONS 
"define _INCL_DEFINITIONS 

"endif // _INCL_DEFINITIONS 

The conditional compilation guard allows the defmitions.sv file to 
be included in multiple files without producing an error when mul- 
tiple files are compiled at the same time. 



10,4 Design top level: squat 



The top level of the design is called squat. This module can pro- 
cess an array of receiver and transmitter utopia interfaces, and 
provide a programmable CPU interface. 

Figure 10-2: Design top-level structural diagram 




The number of Utopia Receive interfaces is defined by a module 
parameter called NumRx, and the number of Utopia Transmit inter- 
faces is defined by a module parameter called NumTx. 

An instance of the interface LookupTable uses the user defined 
data type CellCfgType as the storage data type dType. The 
LookupTable interface is written to by an always_latch block 
which, given a write condition, calls the method lut. write, 
which is the write method in the interface LookupTable. 
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The same interface is read from an alwayscomb block that, given 
a read condition, calls the method lut . read, which is the read 
method in the interface LookupTable. 

Generate blocks are used to iterate across the number of Utopia 
Receive and Transmit interfaces, connecting the interfaces to gen- 
erated instances of utopia receive and transmit modules respec- 
tively. 

The rst reset input is synchronized to the clock, in order to remove 
possible design race conditions. 

A state variable Squatstate in the squat module is defined using 
an enumerated type, followed by a variable of that type. The width 
of the variable is constrained by a range which is used during syn- 
thesis for register sizing. 

typedef enum bit [0:1] { 

wa i t_r x_va lid, 
wa i t_rx_no t_va lid, 
wai t_tx_ready , 

wait__tx_not_ready } StateType; 

StateType Squatstate; 

This variable is used to store the state of the machine when process- 
ing incoming port packets (processed by utopia receive modules), 
prior to transmit (via utopia transmit modules). The state machine 
uses a round robin indicator to balance the precedence of incoming 
packets, which ensures each input port has equal priority for being 
serviced by the forwarding routine. 

Example 10-3: ATM squat top-level module 
"include "definitions . sv" 

module squat 

# (parameter int NumRx = 4, parameter int NumTx = 4) 

(// NumRx x Level 1 Utopia ATM layer Rx Interfaces 
Utopia /* .TopReceive */ Rx [0 :NumRx-l] , 

// NumTx x Level 1 Utopia ATM layer Tx Interfaces 
Utopia /* .TopTransmit */ Tx [0 : NumTx- 1] , 



// Utopia Level 2 parallel management interface 
// Intel -style Utopia parallel management interface 
CPU. Peripheral mif, 
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// Miscellaneous control interfaces 
input wire rst, elk, 

) ; 



// Register file 

LookupTable #(.Asize(8), .dType (CellCfgType) ) lut(); 

// 

// Hardware reset 

// 

logic reset; 

always_££ @(posedge elk) begin 
reset <= rst; 
end 

const bit [2:0] WriteCycle = 3'bOlO; 
const bit [2:0] ReadCycle = 3'bOOl; 
always_latch begin // configure look-up table 
if (mif.BusMode == l'bl) begin 

unique case ({mif.Sel, mif.Rd__DS, mif.Wr_RW}) 
WriteCycle: lut .write (mif .Addr, mif.Dataln); 
endcase 
end 
end 

always_comb begin 

mif .Rdy__Dtack <= l'bz; 
mif.DataOut <= 8'hzz; 
if (mif.BusMode == l'bl) begin 

unique case ({mif.Sel, mif.Rd_DS, mif.Wr_RW}) 
WriteCycle: mif .Rdy_Dtack <= 1'bO; 

ReadCycle: begin 

mif .Rdy__Dtack <= 1'bO; 
mif.DataOut <= lut . read (mif .Addr) ; 
end 

endcase 

end 

end 

// 

// ATM- layer Utopia interface receivers 

// 

genvar Rxlter; 
generate 

for (Rxlter=0; RxIter<NumRx; Rxlter+=1) begin: RxGen 
assign Rx [Rxlter] .clk_in = elk; 
assign Rx [Rxlter] .reset = reset; 
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utopial_atm_rx atm_rx (Rx [Rxlter] . CoreReceive) ; 

end 

endgenerate 

// 

// ATM- layer Utopia interface transmitters 

// 

genvar Txlter; 
generate 

for (Txlter=0; TxIter<NumTx; Txlter+=1) begin: TxGen 
assign Tx [Txlter] . clk__in = elk; 
assign Tx [Txlter] .reset = reset; 
utopial__atm_tx atm_tx (Tx [Txlter] . CoreTransmit) ; 

end 

endgenerate 

// 

// Function to compute the HEC value 

// 

function bit [7:0] hec (input bit [31:0] hdr) ; 
bit [7:0] syndrom [0 : 255] ; 
bit [7:0] RtnCode ; 
bit [7:0] sndrm; 

// Generate the CRC-8 syndrom table 
for (int unsigned i=0; i<256; i+=l) begin 
sndrm = i; 
repeat ( 8 ) begin 
if (sndrm [7] == l'bl) 

sndrm = (sndrm << 1) A 8'h07; 
else 

sndrm = sndrm << 1; 

end 

s yndr om [ i ] = sndrm ; 

end 

RtnCode = 8'h00; 

repeat (4) begin 

RtnCode = syndrom [RtnCode A hdr[31:24]]; 
hdr = hdr << 8; 

end 

RtnCode = RtnCode A 8'h55; 
return RtnCode; 
endf unction 



// 

// Rewriting and forwarding process 

// 
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logic [0:NumTx-l] forward; 

typedef enum bit [0:1] {wait_rx__valid, 

wa i t__rx_no t_v a lid, 
wait_tx_ready, 

wait_tx_not__ready } StateType; 

StateType SquatState; 

bit [0:NumTx-l] Txvalid; 
bit [ 0 : NumTx - 1 ] Txready ; 
bit [0:NumTx-l] Txsel_in; 
bit [0:NumTx-l] Txsel_out; 
bit [0:NumRx-l] Rxvalid; 
bit [0:NumRx-l] Rxready; 
bit [ 0 : NumRx - 1 ] RoundRob in ; 

ATMCellType [0:NumRx-l] RxATMcell ; 

ATMCellType [0:NumTx-l] TxATMcell ; 



generate 

for (Txlter=0; TxIter<NumTx; 
assign Tx[TxIter] .valid 
assign Txready [Txl ter] 
assign Txsel_in [Txlter] 
assign Tx [Txlter] .selected 
assign Tx [Txlter] .ATMcell 

end 

endgenerate 

generate 

for (Rxlter=0; RxIter<NumRx; 
assign Rxvalid [Rxl ter] = 
assign Rx[RxIter] .ready = 
assign RxATMcell [Rxlter] = 

end 

endgenerate 



Txlter+=1) begin: GenTx 
= Txvalid [Txlter] ; 

= Tx [Txlter] .ready; 

= Tx [Txlter] .selected; 

= Txsel_out [Txlter] ; 

= TxATMcell [Txlter] ; 



Rxlter+=1) begin: GenRx 
Rx [Rxlter] .valid; 
Rxready [Rxlter] ; 

Rx [Rxlter] .ATMcell; 



ATMCellType ATMcell; 

always__ff @(posedge clock, posedge reset) begin: FSM 
bit breakVar; 

if (reset) begin: reset_logic 
Rxready <= '1; 

Txvalid <= '0; 

Txsel__out <= '0; 

SquatState <= wait__rx_valid; 
forward <= 0; 

RoundRobin = 1; 
end: reset_logic 
else begin: FSM_sequencer 
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unique case (SquatState) 

wait_rx_valid: begin: rx_valid_state 
Rxready <= ' 1; 
breakVar = 1; 

for (int j = 0 ; j<NumRx; j+=l) begin: loopl 
for (int i=0; i<NumRx; i+=l) begin: loop2 

if (Rxvalid[i] && RoundRobin [i] && breakVar) 
begin: match 

ATMcell <= RxATMcell [i] ; 

Rxready [i] <= 0; 

SquatState <= wait_rx__not_valid; 
breakVar = 0; 
end: match 
end: loop 2 
if (breakVar) 

RoundRobin= {RoundRobin [1 : $bits (RoundRobin) -1] , 
RoundRobin [0] } ; 

end: loopl 
end: rx_valid_state 

wait_rx_not_valid: begin: rx_not_valid_state 

if (ATMcell .uni .HEC != hec (ATMcell .Mem [0 : 3] ) ) begin 
SquatState <= wait__rx__valid; 

"ifndef SYNTHESIS // synthesis ignores this code 
$write("Bad HEC: ATMcell .uni .HEC (0x%x) != "); 

$display ( "ATMcell .Mem [0 : 3] (0x%x) ", 

ATMcell. uni. HEC, hec (ATMcell .Mem [0 : 3] ) ) ; 
"endif 
end 

else begin 

// Get the forward ports & new VPI 
{forward, ATMcell .nni .VPI } <= 
lut . read (ATMcell .uni .VPI) ; 

// Recompute the HEC 

ATMcell. nni. HEC <= hec (ATMcell .Mem [0 : 3] ) ; 
SquatState <= wait_J:x_ready; 

end 

end : r x_no t_va lid_state 

wait_tx_ready : begin: tx_valid_state 
if (forward) begin 

for (int i=0 ; i<NumTx; i+=l) begin 
if (forward[i] && Txready[i]) begin 
TxATMcell [i] <= ATMcell; 

Txvalid[i] <= 1; 

Txsel_out[i] <= 1; 
end 
end 
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SquatState <= wa it_tx_no thready ; 

end 

else begin 

SquatState <= wait__rx_valid; 

end 

end: tx_valid__state 

wait_ tx_not_ready : begin: tx_not_valid_state 
for (int i=0 ; i<NumTx; i+=l) begin 

if (forward[i] && ITxreadyti] && Txsel_in [i] ) begin 
Txvalid[i] <= 0; 

Txsel_out[i] <= 0; 
forward [i] <= 0; 
end 
end 

if (forward) 

SquatState <= wait_tx__ready; 

else 

SquatState <= wait__rx_valid; 
end: tx_not_valid_state 

default: begin: unknown_state 
SquatState <= wait__rx_valid; 

'ifndef SYNTHESIS // synthesis ignores this code 
$display( "Unknown condition"); $finish(); 

'endif 

end: unknown__state 

endcase 

end: FSM__sequencer 
end : FSM 
endmodule 
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always__£f @(posedge Rx.clk_in, posedge Rx. reset) begin: FSM 
if (Rx. reset) begin 
Rx. valid <= 0; 

Rx.en <= 1; 

UtopiaStatus <= reset; 

end 

else begin: FSM_sequencer 
unique case (UtopiaStatus) 
reset: begin: reset_state 
if (Rx. ready) begin 
UtopiaStatus <= soc; 

Rx.en <= 0; 
end 

end: reset_state 

soc: begin: soc_state 

if (Rx.soc && Rx.clav) begin 
{ Rx . ATMcell . uni . GFC , 

Rx. ATMcell .uni . VPI [7:4] } <= Rx.data; 

UtopiaStatus <= vpi_vci; 
end 

end: soc_state 

vpi_vci: begin: vpi_vci__state 
if (Rx.clav) begin 

{Rx. ATMcell. uni. VPI [3:0] , 

Rx. ATMcell. uni. VCI [15:12] } <= Rx.data; 
UtopiaStatus <= vci; 
end 

end: vpi_vci_state 

vci: begin: vci_state 
if (Rx.clav) begin 

Rx. ATMcell .uni .VCI [11 : 4] <= Rx.data; 

UtopiaStatus <= vci_clp_jpt; 

end 

end: vci_state 

vci_clp_pt: begin: vci_clp_pt_state 
if (Rx.clav) begin 

{Rx. ATMcell. uni. VCI [3:0] , Rx. ATMcell .uni . CLP, 

Rx. ATMcell .uni .PT} <= Rx.data; 

UtopiaStatus <= hec; 

end 

end: vci__clp_j?t_state 

hec: begin: hec_state 
if (Rx.clav) begin 

Rx. ATMcell .uni .HEC <= Rx.data; 

UtopiaStatus <= payload; 
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Payloadlndex =0; /* Blocking Assignment, due to 

blocking increment in 
payload state */ 

end 

end: hec__state 

payload: begin: payload_state 
if (Rx.clav) begin 

Rx.ATMcell .uni . Payload [Payloadlndex] <= Rx.data; 
if (PayloadIndex==47) begin 
UtopiaStatus <= ack; 

Rx. valid <= 1; 

Rx.en <= 1; 
end 

PayloadIndex++ ; 

end 

end: payload_state 

ack: begin: ack_state 
if (!Rx. ready) begin 
UtopiaStatus <= reset; 

Rx. valid <= 0; 

end 

end: ack_state 

default: UtopiaStatus <= reset; 

endcase 

end: FSM_sequencer 
end: FSM 
endmodule 
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10.5.2 Transmitter state machine 

The transmitter in the generate loop has a state machine with 9 
states. 



Figure 10-4: Transmitter state flow diagram 




Example 10-5: Utopia ATM transmitter 

module utopial_ atm_tx ( Utopia. CoreTransmit Tx ) ; 
assign Tx.clk_out = Tx.clk_in; 
logic [0:5] Payloadlndex; // 0 to 47 

enum bit [0:3] { reset, soc, vpi_vci, vci, vci__clp_pt, hec, 
payload, ack, done } UtopiaStatus; 





Chapter 10: A Complete Design Modeled with SystemVerilog 



281 



always_ff @(posedge Tx.clk_in, posedge Tx. reset) begin: FSM 
if (Tx. reset) begin 
Tx.soc <= 0; 

Tx.en <= 1; 

Tx. ready <= 1; 

UtopiaStatus <= reset; 
end 

else begin: FSM_sequencer 
unique case (UtopiaStatus) 
reset: begin: reset_state 
Tx.en <= 1; 

Tx. ready <= 1; 
if (Tx. valid) begin 
Tx. ready <= 0; 

UtopiaStatus <= soc; 
end 

end: reset_state 

soc: begin: soc_state 
if (Tx.clav) begin 
Tx.soc <= 1; 

Tx.data <= Tx.ATMcell .nni .VPI [11 : 4] ; 

UtopiaStatus <= vpi_vci; 

end 

Tx.en <= ! Tx.clav; 
end: soc_state 

vpi_vci: begin: vpi_vci_state 
Tx.soc <= 0; 
if (Tx.clav) begin 

Tx.data <= {Tx.ATMcell .nni .VPI [3:0] , 

Tx.ATMcell. nni. VCI [15:12] } ; 
UtopiaStatus <= vci; 
end 

Tx.en <= iTx.clav; 
end: vpi_vc instate 

vci: begin: vci__state 
if (Tx.clav) begin 

Tx.data <= Tx.ATMcell .nni .VCI [11 : 4] ; 

UtopiaStatus <= vci_clp_j?t; 

end 

Tx.en <= ! Tx.clav; 
end: vci_jstate 

vci__clp__pt : begin: vci_clp_p testate 
if (Tx.clav) begin 

Tx.data <= {Tx.ATMcell .nni .VCI [3 : 0] , 

Tx.ATMcell .nni . CLP, Tx.ATMcell .nni . PT} ; 
UtopiaStatus <= hec; 
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end 

Tx.en <= ITx.clav; 
end: vci_clp_pt_state 

hec: begin: hec_state 
if (Tx.clav) begin 

Tx.data <= Tx. ATMcell .nni .HEC; 

UtopiaStatus <= payload; 

Payloadlndex = 0; 
end 

Tx.en <= ITx.clav; 
end: hec_state 

payload: begin: payload_state 
if (Tx.clav) begin 

Tx.data <= Tx. ATMcell .nni . Payload [Payloadlndex] ; 
if (PayloadIndex==47) UtopiaStatus <= ack; 
PayloadIndex++ ; 

end 

Tx.en <= ITx.clav; 
end: payload_j3tate 

ack: begin: ack__state 
Tx.en <= 1; 
if (ITx. valid) begin 
Tx. ready <= 1; 

UtopiaStatus <= done; 
end 

end: ack__state 

done: begin: done_state 
if (ITx. valid) begin 
Tx. ready <= 0; 

UtopiaStatus <= reset; 

end 

end: done_state 

endcase 

end : FSM_sequencer 
end: FSM 
endmodule 
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10.6 Testbench 



The testbench send and receive methods for the Utopia interface are 
encapsulated in the UtopiaMethod interface. 

Example 10-6: UtopiaMethod interface for encapsulating test methods 

Interface UtopiaMethod; 

task automatic Initialise (); 
endtask 

task automatic Send (input ATMCellType Pkt, input int PortID) ; 
static int PacketID; 

PacketID++; 

Pkt.tst. PortID = PortID; 

Pkt.tst. PacketID = PacketID; 

// iterate through bytes of packet, deasserting 
// Start Of Cell indicater 
@ (negedge Utopia . clk_out ) ; 

Utopia. clav <= 1; 
for (int i=0; i<=52; i++) begin 
//If not enabled, loop 

while (Utopia. en === l'bl) ©(negedge Utopia. clk_out) ; 

// Assert Start Of Cell indicater, assert enable, 

// send byte 0 (i==0) 

Utopia. soc <= (i==0) ? l'bl : 1'bO; 

Utopia. data <= Pkt.Mem[i]; 

@ (negedge Utopia . clk_out) ; 
end 

Utopia. data <= 8'bx; 

Utopia. clav <= 0; 

endtask 

task automatic Receive (input int PortID) ; 

ATMCellType Pkt; 

Utopia. clav = 1; 

while (Utopia. soc !==l'bl && Utopia. en ! ==1 'bO) 

@ (negedge Utopia . clk_out ) ; 
for (int i=0 ; i<=52; i++) begin 
// If not enabled, loop 

while (Utopia. en!==l 'bO) @(negedge Utopia . clk__out) ; 

Pkt. Mem [i] = Utopia. data; 

@ (negedge Utopia . clk_out ) ; 

end 
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Utopia. clav = 0; 

// Write Rxed data to logfile 
"ifdef verbose 

$write ( "Received packet at port %0d from port %0d 
PKT (%0d) \n" , 

PortID, Pkt . tst . PortID, Pkt . tst . PacketID) ; 

//Port ID, Pkt. nni. Pay load [0] , Pkt. nni. Pay load [1:4] ) ; 
"endif 

endtask 

endinterface 



The testbench HostWrite and HostRead methods for the CPU 
interface are encapsulated in the CPUMethod interface. 

Example 10-7: CPUMethod interface for encapsulating test methods 

interface CPUMethod; 

task automatic Initialise Jfost (); 

CPU . BusMode <= 1; 

CPU . Addr <= 0; 

CPU.Dataln <= 0; 

CPU.Sel <= 1; 

CPU . Rd_DS <= 1; 

CPU . Wr_RW <= 1; 
endtask 

task automatic HostWrite (int a, CellCfgType d) ; // configure 
#10 CPU. Addr <= a; CPU.Dataln <= d; CPU.Sel <= 0; 

#10 CPU . Wr__RW <= 0; 

while (CPU. Rdy__D tack ! ==0) #10; 

#10 CPU . Wr_RW <= 1; CPU.Sel <= 1; 
while (CPU.Rdy_Dtack==0) #10; 
endtask 

task automatic HostRead (int a, output CellCfgType d) ; 

#10 CPU. Addr <= a; CPU.Sel <= 0; 

#10 CPU. Rd JDS <= 0; 

while (CPU. Rdy_D tack ! ==0) #10; 

#10 d = CPU.DataOut ; CPU.Rd_DS <= 1; CPU.Sel <= 1; 
while ( CPU . Rdy__Dt ack= = 0 ) #10; 

endtask 

endinterface 
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The main testbench module uses the encapsulated methods listed 
above. 

Example 10-8: Utopia ATM testbench 

"include "definitions . sv" 

" include "methods . sv" 

module test; 

parameter int NumRx = "RxPorts; 
parameter int NumTx = "TxPorts; 

// NumRx x Level 1 Utopia Rx Interfaces 
Utopia Rx [0 : NumRx- 1] ; 

// NumTx x Level 1 Utopia Tx Interfaces 
Utopia Tx [ 0 : NumTx- 1 ] ; 

// Intel -style Utopia parallel management interface 
CPU mif ; 

// Miscellaneous control interfaces 

logic rst; 

logic elk; 

logic Initialised; 

" include " . /testbenchJLnstance . sv" 

task automatic RandomPkt (inout ATMCellType Pkt, inout seed) ; 
Pkt.uni.GFC = $random (seed) ; 

Pkt.uni.VPI = $random (seed) & 8'hff; 

Pkt.uni.VCI = $random(seed) ; 

Pkt. uni. CLP = $random(seed) ; 

Pkt. uni. PT = $random(seed) ; 

Pkt .uni .HEC = hec (Pkt .Mem [0 : 3] ) ; 
for (int i=0 ; i<=47; i++) begin 

Pkt .uni. Pay load [i] = 47-i; //$ random (seed) ; 
end 

endtask 

logic [7:0] syndrom [0 : 255] ; 
initial begin: gen_syndrom 
int i; 

logic [7:0] sndrm; 

for (i = 0; i < 256; i = i + 1 ) begin 
sndrm = i ; 
repeat ( 8 ) begin 

if ( sndrm [ 7 ] === l'bl) 
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sndrm = (sndrm << 1) A 8'h07; 

else 

sndrm = sndrm << 1; 

end 

syndrom [i] = sndrm; 

end 

end 

// Function to compute the HEC value 
function automatic bit [7:0] hec (bit [31:0] hdr) ; 
bit [7:0] rtn; 
rtn = 8'h00; 
repeat (4) begin 

rtn = syndrom [rtn A hdr [31: 24]]; 
hdr = hdr << 8; 
end 

rtn = rtn A 8'h55; 
return rtn; 
endfunction 

// System Clock and Reset 



initial begin 




#0 rst = 0; 


elk = 0; 


#5 rst = 1; 




#5 Clk = 1; 




#5 rst = 0; 


elk = 0; 


forever begin 



#5 elk = 1; 



#5 elk = 0; 

end 

end 

CellCfgType lookup [255:0]; // copy of look-up table 

function bit [0:NumTx-l] find (bit [11:0] VPI) ; 
for (int i=0; i<=255; i++) begin 
if (lookup [i] .VPI == VPI) begin 
return lookup [i] . FWD; 

end 

end 

return 0; 
endfunction 

// Stimulus 
initial begin 

automatic int seed=l; 

CellCfgType CellFwd; 
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$display ("Configuration RxPorts=%0d TxPorts=%0d" , 
'RxPorts, "TxPorts) ; 
mif .Method. Initialise__Host ( ) ; 

// Configure through Host interface 
repeat (10) @(negedge elk); 

$di splay ( "Loading Memory" ) ; 
for (int i=0; i<=255; i++) begin 
CellFwd. FWD = i; 
v ifdef FWDALL 

CellFwd. FWD = ' 1; 

'endif 

CellFwd. VPI = i; 

mif .Method. HostWrite (i, CellFwd) ; 
lookup [i] = CellFwd; 

end 

// Verify memory 
$di splay ( "Verifying Memory" ) ; 
for (int i=0 ; i<=255; i++) begin 
mif .Method.HostRead(i, CellFwd) ; 
if (lookup [i] ! = CellFwd) begin 

$display( "Error, Mem Location 0x%x contains 0x%x, 
expected 0 x%x", 

i, lookup [i], CellFwd); 

$stop; 

end 

end 

$di splay ( "Memory Verified"); 

Initialised=l; 

repeat (5000000) @(negedge elk) ; 

$display ( "Error Timeout"); 

$f inish; 

end 

int TxPktCtr [0:NumTx-l]; 
bit [0:NumRx-l] RxGenlnProgress ; 
genvar Rxlter; 
genvar Txlter; 

generate // replicate access to ports 

for (Rxlter=0; RxIter<NumRx; Rxlter++) begin: RxGen 
initial begin: Sender 
int seed; 

bit [0 :NumTx-l] TxPortTarget ; 

ATMCellType Pkt; 



Rx [Rxlter] .data=0; 
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Rx [Rxlter] .soc=0; 

Rx[RxIter] .en*=l; 

Rx[RxIter] . clav=0; 

Rx[RxIter] . ready=0; 

RxGen InProgress [Rxlter] = 1; 
wait (Initialised === l'bl); 
seed=RxIter+l; 

Rx [Rxlter] .Method. Initialise () ; 
repeat (200) begin 
RandomPkt ( Pkt , seed); 

TxPortTarget = f ind (Pkt .uni . VPI) ; 

// Increment counter if output packet expected 
for (int i=0; i<NumTx; i++) begin 
if (TxPortTarget [i] ) begin 
TxPktCtr [i] ++; 

//$display ( "port %0d ->> %0d", Rxlter, i) ; 

end 

end 

Rx [Rxlter] .Method. Send (Pkt, Rxlter) ; 

//$display ("Port %d sent packet", Rxlter); 
repeat ($random(seed) %200) @(negedge elk); 
end 

RxGenlnProgress [Rxlter] = 0; 

end 

end 

endgenerate 

// Response - open files for response 

generate 

for (Txlter=0; TxIter<NumTx; Txlter++) begin: TxGen 
initial begin: Receiver 

wait (Tx[TxIter] .reset===l) ; 
wait (Tx[TxIter] .reset===0) ; 
forever begin 

Tx[TxIter] . Method. Receive (Txlter) ; 

TxPktCtr [Txlter] - - ; 

end 

end 

end 

endgenerate 

// Check for all detected packets 
bit [0 :NumTx-l] TxDetectEnd; 

generate 

for (Txlter=0; TxIter<NumTx; Txlter++) begin: TxDetect 
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initial begin 

TxDetectEnd [Txlter] = l'bl; 
wait (Initialised === l'bl); 
wait (RxGenlnProgress === 0) ; 
wait (TxPktCtr [Txlter] == 0) 
TxDetectEnd [Txlter] = 1'bO; 

$display ("TxPktCtr [%0d] == %d" / 

Txlter, TxPktCtr [Txlter] ) ; 

end 

end 

endgenerate 
initial begin 

wait (Initialised === l'bl); 
wait (RxGenlnProgress === 0) ; 
wait (TxDetectEnd === 0) ; 

$f inish; 

end 

endmodule 



The testbench instance of the design is contained in a separate file, 
so that pre-and post-synthesis versions can be used. 

squat #(NumRx, NumTx) squat (Rx, Tx, mif, rst, elk); 



10,7 Summary 



This chapter has presented a larger example, modeled using the 
SystemVerilog extensions to the Verilog HDL. Structures are used 
to encapsulate all the variables related to NNI and uni packets. This 
allows these many individual signals to be referenced using the 
structure names, instead of having to reference each signal individ- 
ually. This encapsulation simplifies the amount of code required to 
represent complex sets of information. The concise code is easier to 
read, to test, and to maintain. 

These nni and uni structures are grouped together as a union, 
which allows a single piece of storage to represent either type of 
packet. Because the union is packed, a value can be stored as one 
packet type, and retrieved as the other packet type. This further 
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simplifies the code required to transfer a packet from one format to 
another. 

The communication between the major blocks of the design is 
encapsulated into interfaces. This moves the declarations of the 
several ports of each module in the design to a central location. The 
port declarations within each module are minimized to a single 
interface port. The redundancy of declaring the same ports in sev- 
eral modules is eliminated. 

SystemVerilog constructs are also used to simplify the code 
required to verify the design. The same union used to store the NNI 
and uni packets is used to store test values as an array of bytes. The 
testbench can load the union variable using bytes, and the value can 
be read by the design as an NNI or uni packet. It is not necessary to 
copy test values into each variable that makes up a packet. 

SystemVerilog includes a large number of additional enhancements 
for verification that are not illustrated in this example. These 
enhancements are covered in the forthcoming companion book, 
SystemVerilog for Verification. 




Chapter 11 

Behavioral and Transaction 

Level Modeling 



r his chapter defines Transaction Level Modeling (TLM) as an 
adjunct to behavioral modeling. The chapter explains how 
TLM can be used, and shows how SystemVerilog is suited to TLM. 

Behavioral modeling can be used to provide a high level executable 
specification for development of both RTL code and the testbench. 
Transaction level modeling allows the system executable specifica- 
tion to be partitioned into executable specifications of the sub- 
systems. 

The executable specifications shown in this chapter are generally 
not considered synthesizable. However, there are some tools called 
“high level” or “behavioral” synthesis tools which are able to han- 
dle particular categories of behavioral or transaction level model- 
ing. 

The topics covered in this chapter include: 

• Definition of a transaction 
• Transaction level model of a bus 
• Multiple slaves 

• Arbitration between multiple masters 
• Semaphores 

• Interfacing transaction level with register transfer level models 
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11,1 Behavioral modeling 



Behavioral modeling (or behavior level modeling) is a style where 
the state machines of the control logic are not explicitly coded. 

An implicit state machine is an always block which has more than 
one event control in it. For instance, the following code generates a 
1 pulse after the reset falls: 

always begin 

do @(posedge clock) while (reset); 

@(posedge clock) a = 1; 

@(posedge clock) a » 0; 

end 

An RTL description would have an explicit state register, as fol- 
lows: 

logic [1:0] state; 

always_ff @(posedge clock) 
if (reset) state = 0; 
else if (state == 0) 

begin state = 1; a = 1; end 
else if (state == 1) 

begin state = 2; a = 0; end 
else state = 0; 

Note that there is an even more abstract style of behavioral model- 
ing that is not cycle-accurate, and therefore can be used before the 
detailed scheduling of the design as an executable specification. An 
example is an image processing algorithm that is to be implemented 
in hardware. 



11.2 What is a transaction? 



In everyday life, a transaction is an interaction between two people 
or organizations to transfer information, money, etc. In a digital 
system, a transaction is a transfer of data and control between two 
subsystems. This normally means a request and a response. A trans- 
action has attributes such as type, data, start time, duration, and sta- 
tus. It may also contain sub-transactions. 
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A key concept of TLMs is the suppressing of uninteresting parts of 
the communication. For example, if a customer has to pay $20 for a 
book in a shop, he can perform the transaction at many levels. 

Lowest level — 20 transactions of $1 each 

“$20 please” 

“Here is $1”, hands over the $1 bill 
“Thanks” 

“Here is $1”, hands over the $1 bill 
“Thanks” 

“Here is $1”, hands over the $1 bill 
“Thanks” 

... (17 more $1 transactions) 

“OK that’s $20, here is the book” 

“Thanks” 

Slightly higher level — 4 transactions of $5 each 

“$20 please” 

“Here is $5”, hands over the $5 bill 
“Thanks” 

“Here is $5”, hands over the $5 bill 
“Thanks” 

“Here is $5”, hands over the $5 bill 
“Thanks” 

“Here is $5”, hands over the $5 bill 
“OK that’s $20, here is the book” 

“Thanks” 

Higher level — 1 transaction of $20 

“$20 please” 



“Here is $20”, hands over the $20 bill 
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“OK that’s $20, here is the book” 
“Thanks” 



This illustrates a key benefit of TLMs, that of efficiency. Engineers 
only need to model the level that they are interested in. One of the 
key motivators in the use of TLMs is the hiding of the detail such 
that the caller does not know the details of the transactions. This 
provides a much higher level representation of the interface 
between blocks. 

Note that it is not just the abstracting of the data (e.g. using the $20 
total), but also the removal of the control (less low level communi- 
cation), that increases the TLM abstraction and potential simulation 
performance. At the highest level, the book buyer is only interested 
in paying the $20, and does not really care whether it is in $ Is or 
$5s or a $20. Hiding detail allows different implementations of a 
protocol to exist without the caller knowing, or needing to know, 
which level is being used, and then being able to switch in and out 
different TLMs as needed. Switching in and out different TLMs 
may be done for efficiency reasons, to use a less detailed more effi- 
cient TLM, or maybe during the life of a project, where in the 
beginning only high level details are defined, and then, more details 
are added over the life of the project. 



11.3 Transaction level modeling in SystemVerilog 



Whereas behavior level modeling raises the abstraction of the block 
functionality, transaction level modeling raises the abstraction level 
of communication between blocks and subsystems, by hiding the 
details of both control and data flow across interfaces. 

In SystemVerilog, a key use of the interface construct is to be 
able to separate the descriptions of the functionality of modules and 
the communication between them. 

Transaction level modeling is a concept, and not a feature of a spe- 
cific language, though there are certain language constructs that are 
useful for writing transaction level models (TLMs). These include: 

• Structural hierarchy 
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• Function and task calls across hierarchy boundaries 

• Records or structures 

• The ability to package data with function/task calls 

• The ability to parallelize and serialize data 

• Semaphores to control shared resources 

A fundamental capability that is needed for TLMs is to be able to 
encapsulate the lower level details of information exchange into 
function and task calls across an interface. The caller only needs to 
know what data is sent and returned, with the details of the trans- 
mission being hidden in the function/task call. 

The transaction request is made by calling the task or function 
across the interface/module boundary. Using SystemVerilog’s 
interface and function/task calling mechanisms makes creating 
TLMs in SystemVerilog extremely simple. The term method is 
used to describe such function/task calls, since they are similar to 
methods in object-oriented languages. 

11.3.1 Memory subsystem example 

Example 11-1 illustrates a simple memory subsystem. Initially this 
is coded as read and write tasks called by a single testbench. The 
testbench tries a range of addresses, and tests the error flag. 

Example 11-1: Simple memory subsystem with read and write tasks 
module TopTasks; 

logic [20:0] A; 
logic [15:0] D; 
logic E; 

parameter LOWER = 20'h00000; 
parameter UPPER = 20'h7ffff; 
logic [15:0] Mem [LOWER: UPPER] ; 

task ReadMem ( input logic [19:0] Address, 
output logic [15:0] Data, 
output bit Error) ; 

if (Address >= LOWER && Address <= UPPER) begin 
Data = Mem [Address] ; 

Error = 0; 
end 
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else Error = 1; 

endtask 

task WriteMem (input logic [19:0] Address, 

input logic [15:0] Data, 

output bit Error) ; 

if (Address >= LOWER && Address <= UPPER) begin 

Mem [Address] = Data; 

Error = 0; 
end 

else Error = 1; 

endtask 

initial begin 

for (A = 0; A < 21 1 hi 00000 ; (A = A + 21'h40000)) begin 
fork 
# 1000 ; 

WriteMem (A [19 : 0] , 0, E) ; 

join 

if (E) $display ("%t bus error on write %h", $time, A); 
else $display ("%t write OK %h", $time, A); 

fork 

# 1000 ; 

ReadMem (A [19 : 0] , D, E) ; 
join 

if (E) $display ("%t bus error on read %h" , $time, A); 
else $display ("%t read OK %h", $time, A); 

end 

end 

endmodule : TopTasks 



This example gives the following display output: 

1000 write OK 000000 

2000 read OK 000000 

3000 write OK 040000 

4000 read OK 040000 

5000 bus error on write 080000 

6000 bus error on read 080000 

7000 bus error on write OcOOOO 

8000 bus error on read OcOOOO 
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11.4 Transaction level models via interfaces 



The next example partitions the memory subsystem into three mod- 
ules, two memory units and a testbench. The modules are con- 
nected by an interface. In this design, the address regions are wired 
into the memory units. One, and only one, memory should respond 
to each read or write. If no unit responds, there is a bus error. 

This broadcast request with single response can be conveniently 
modeled with the extern fork join task construct in SystemVer- 
ilog interfaces. This behaves like a fork.. .join containing multi- 
ple task calls. The difference is that the number of calls is not 
defined, which allows the same interface code to be used for any 
number of memory units. The output values are written to the actual 
arguments for each task call, and the valid task call delays its 
response so that it overwrites the invalid ones. 

Example 1 1-2: Two memory subsystems connected by an interface 
module TopTLM ; 

Membus Mbus ( ) ; 

Tester T (Mbus) ; 

Memory # ( .Lo (20 ' hOOOOO) # .Hi (20 ' h3f f f f ) ) 

Ml (Mbus); // lower addrs 

Memory # ( .Lo (20 'h40000) , .Hi (20 ' h7f f f f ) ) 

M2 (Mbus); // higher addrs 

endmodule : TopTLM 



// Interface header 
interface Membus; 

extern fork join task ReadMem ( input logic [19:0], 

output logic [15:0], 
bit) ; 

extern forkjoin task WriteMem( input logic [19:0], 

input logic [15:0], 
output bit) ; 



extern task Request ( ) ; 
extern task Relinquish () ; 



endinterface 
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module Tester (interface Bus) ; 

logic [15:0] D; 
logic E; 



int A; 

initial begin 

for (A = 0; A < 21'hlOOOOO; A = A + 21'h40000) begin 
fork 
# 1000 ; 

Bus . WriteMem (A [19 : 0] , 0, E) ; 
join 

if (E) $display ("%t bus error on write %h" # $time, A); 
else $display ("%t write OK %h" / $time, A); 

fork 

# 1000 ; 

Bus .ReadMem(A[19 : 0] , D, E) ; 
join 

if (E) $display (”%t bus error on read %h", $time # A) ; 
else $display ("%t read OK %h" # $time, A) ; 

end 

end 

endmodule 



// Memory Modules 

// fork join task model delays if OK (last wins) 
module Memory (interface Bus); 

parameter Lo = 20'h00000; 
parameter Hi = 20'h3ffff; 
logic [15:0] Mem[Lo:Hi] ; 

task Bus .ReadMem( input logic [19:0] Address, 
output logic [15:0] Data, 
output bit Error) ; 

if (Address >= Lo && Address <= Hi) begin 
#100 Data = Mem [Address] ; 

Error = 0; 

end 

else Error = 1; 

endtask 




Chapter 11: Behavioral and Transaction Level Modeling 



299 



task Bus .Wr it eMem( input logic 
input logic 
output bit 



[19:0] Address, 
[15:0] Data, 

Error) ; 



if (Address >= Lo && Address <= Hi) begin 
#100 Mem [Address] = Data/ 

Error = 0; 

end 

else Error = 1; 

endtask 



endmodule 



This example gives the following display output: 

1000 write OK 000000 

2000 read OK 000000 

3000 write OK 040000 

4000 read OK 040000 

5000 bus error on write 080000 

6000 bus error on read 080000 

7000 bus error on write OcOOOO 

8000 bus error on read OcOOOO 



11.5 Bus arbitration 



If there are two bus masters, it is necessary to prevent both masters 
from accessing the bus at the same time. The abstract mechanism 
for modeling such a resource sharing is the semaphore . SystemVer- 
ilog includes a built-in semaphore class object. In this chapter, 
however, an interface model is used. This illustrates how the class 
behavior can be described, using interfaces and interface methods. 

The Semaphore interface in the following example has a number 
of keys, corresponding to resources. The default is one. The get 
task waits for the key(s) to be available, and then removes them. 
The put task replaces the key(s). 

The model below has an arbiter module containing the sema- 
phore. An alternative would be to put the semaphore in the inter- 
face, but this would differ from the RTL implementation hierarchy. 
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Example 11-3: TLM model with bus arbitration using semaphores 

module TopArbTLM; 

Membus Mbus ( ) ; 

Tester Tl(Mbus); 

Tester T2 (Mbus) ; 

Arbiter A (Mbus) ; 

Memory # ( .Lo (20 ' hOOOOO) , .Hi (20 ' h3f f f f ) ) Ml (Mbus); 
Memory # ( .Lo (20 ' h40000) , .Hi (20 1 h7f f f f ) ) M2(Mbus); 

endmodule : TopArbTLM 



interface Membus; // repeated from previous example 



extern fork join task ReadMem ( input logic [19:0], 

output logic [15:0], 
bit) ; 



extern forkjoin task WriteMem( input logic [19:0], 

input logic [15:0], 
output bit) ; 



extern task Request ( ) ; 
extern task Relinquish () ; 

endinterface 



interface Semaphore # (parameter int unsigned initial_keys = 1;); 
int unsigned keys = initial_keys; 

task get (int unsigned n = 1); 
wait (n <= keys) ; 
keys -= n; 

endtask 

task put (int unsigned n = 1) ; 

keys += n; 
endtask 

endinterface 



module Arbiter (interface Bus) ; 

Semaphore s; // built-in type would use semaphore s = new; 
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task Bus .Request () ; 
s.get () ; 

endtask 

task Bus.RelinquishO ; 
s.put () ; 

endtask 

endmodule 



module TesterArb (Interface Bus) ; 
logic [15:0] D; 
logic E; 

int A; 

Initial begin : test_block 

for (A = 0; A < 21'hlOOOOO; A = A + 21'h40000) 
begin : loop 
fork 
# 1000 ; 
begin 

Bus .Request ; 

Bus.WriteMem(A[19:0] , 0, E) ; 

if (E) $display ("%t bus error on write %h", $time, A) ; 

else $display ("%t write OK %h", $time, A); 

Bus .Relinquish; 
end 
join 
fork 
# 1000 ; 
begin 

Bus .Request ; 

Bus . ReadMem (A [19 : 0] , D, E) ; 

if (E) $display ( "%t bus error on read %h" / $time, A) ; 

else $display ("%t read OK %h", $time, A) ; 

Bus .Relinquish ; 

end 

join 

end : loop 
end : test block 



endmodule 
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// Memory Modules 

// forkjoin task model delays if OK (last wins) 

module Memory (interface Bus) ; // repeated from previous example 



parameter Lo = 20'h00000; 
parameter Hi = 20'h3ffff; 
logic [15:0] Mem[Lo:Hi]; 



task Bus . ReadMem ( input logic [19:0] Address, 
output logic [15:0] Data, 
output bit Error) ; 



if (Address >= Lo && Address <= Hi) begin 
#100 Data = Mem [Address] ; 

Error = 0; 

end 

else Error = 1; 

endtask 

task Bus .WriteMem( input logic [19:0] Address, 

input logic [15:0] Data, 

output bit Error) ; 

if (Address >= Lo && Address <= Hi) begin 

#100 Mem [Address] = Data; 

Error = 0; 

end 

else Error = 1; 

endtask 



endmodule 



This example gives the following output: 

100 write OK 00000000 

200 write OK 00000000 

1100 read OK 00000000 

1200 read OK 00000000 

2100 write OK 00040000 

2200 write OK 00040000 

3100 read OK 00040000 

3200 read OK 00040000 

4000 bus error on write 00080000 

4000 bus error on write 00080000 

5000 bus error on read 00080000 
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5000 bus error on read 00080000 
6000 bus error on write 000C0000 
6000 bus error on write 000C0000 
7000 bus error on read 000C0000 
7000 bus error on read OOOcOOOO 



11.6 Transactors, adapters, and bus functional models 



For TLMs to be useful for hardware design, it is necessary to con- 
nect them to the RTL models via code which is variously called 
transactors , adapters , and bus functional models ( BFMs ). These 
can be either master or slave adapters, depending on the direction of 
control. 

The master adapter contains tasks, called by the master subsystem 
TLM, which encapsulate the protocol and manipulate the signals to 
communicate with an RTL model of the slave subsystem. 

The slave adapter contains processes, which monitor signals from 
an RTL model of the master subsystem and call the tasks or func- 
tions in the TLM of the slave subsystem. 

11.6.1 Master adapter as module 

One way to code adapters is to make them modules which translate 
a transaction level interface to a pin level interface, or vice-versa. 
The adapter has two interface ports, the transaction level and the 
pin level. 

Example 11-4: Adapter modeled as a module 
module TopTLMPLM; 

Multibus TLMbus ( ) ; 

Multibus PLMbus ( ) ; 

Tester T (TLMbus); 

MultibusMaster MM (TLMbus, PLMbus) ; 

MultibusArbiter MA (PLMbus) ; 

Clock Clk ( PLMbus); 

MultibusMonitor MO (PLMbus); 



MemoryPIN # ( . Lo (20 ’ hOOOOO) , .Hi (20 ' h3f f f f ) ) 
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Ml (PLMbus.ADR, PLMbus.DAT, PLMbus . MRDC , PLMbus. MWTC, 
PLMbus . XACK # PLMbus . BCLK) ; 

MemoryPIN # ( .Lo (20 1 h40000) , .Hi (20 ' h7f f f f ) ) 

M2 (PLMbus.ADR, PLMbus.DAT, PLMbus. MRDC, PLMbus. MWTC, 
PLMbus . XACK, PLMbus . BCLK) ; 

endmodule : TopTLMPLM 



The example below is a simplified version of the Intel Multibus 
(now IEEE 796). This allows multiple masters and multiple slaves. 
Each master has a request wire BREQ to the arbiter module and a 
priority input wire BPRN from the arbiter, i.e. the parallel priority 
technique specified in the standard. 



Example 11-5: Simplified Intel Multibus with multiple masters and slaves 

// Interface header 
interface Multibus; 

parameter int MASTERS = 1; // number of bus masters 



// structural communication 
tri [19:0] 
tri [15:0] 

wand /*active0*/ MRDC, 

wand /*active0*/ 

wand /*active0*/ [1 : MASTERS] 

wand /*active0*/ 

wire /*active0*/ 

wire /*active0*/ [1 : MASTERS] 

logic 

logic 

wand 



ADR; // address bus (inverted) 
DAT; // data bus (inverted) 
MWTC; // mem read/ write commands 
XACK; // transfer acknowledge 
BREQ; // bus request 
CBRQ ; // common bus request 
BUSY; // bus busy 
BPRN; // bus priority to master 
BCLK; // bus clock; driven 
//by only one master 
CCLK ; // constant clock 
INIT; // initialize 



// Tasks - Behavioral communication 

extern task Request (input int) ; 

extern task Relinquish (input int) ; 

extern fork join task ReadMem (input logic [19:0], 

output logic [15:0], 
bit) ; 
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extern fork join task WriteMem (input logic 

input logic 
output bit) ; 



[19:0] , 
[15:0] , 



endinterface 



module Clock (Multibus Bus) ; 

always begin // clock 
#50 Bus . CCLK = 0; 

#50 BUS. CCLK = 1; 

end 

endmodule : Clock 



The master adapter is coded with tasks which drive wires and have 
the same prototype as the transaction level slave. If only a single 
driver is allowed for a wire, a logic variable can be used directly. If 
multiple drivers are allowed, the adapter needs a continuous assign- 
ment to model the buffering to the wire. 

If the master does not already have control of the bus, the master 
has to request it from the arbiter, wait for the priority to be granted, 
and then wait for the previous master to relinquish the bus. These 
actions are encapsulated in the task GetBus. 

If no slave responds to the address, then a time out occurs and the 
read or write task returns with the error flag set. 



Example 1 1-6: Simple Multibus TLM example with master adapter as a module 

module MultibusMaster (interface Tasks, interface Wires) ; 
parameter int Number =1; // number of master for 

// request /grant 



enum {IDLE, READY, READ, WRITE} Master_State; 



logic [19:0] adr = ' z; 

logic [15:0] dat = 'z; 

logic mrdc = 1; 

logic mwtc = 1; 

logic breq = 1; 

logic cbrq = 1; 



assign Wires. ADR = adr; 
assign Wires.DAT = dat; 
assign Wires. MRDC = mrdc; 
assign Wires. MWTC = mwtc; 
assign Wires . BREQ [Number] 
assign Wires. CBRQ = cbrq; 



breq; 
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logic busy = 1; assign Wires. BUSY = busy; 

assign Wires. BCLK = Wires. CCLK; 

task Tasks . ReadMem (input logic [19:0] Address, 

output logic [15:0] Data, 

output bit Error) ; 

if (MasterjState == IDLE) GetBusO; 

else assert (MasterjState == READY) ; 

Master_State = READ; 

Data = 'x; Error =1; // default if no slave responds 

adr = -Address; 

#50 mrdc = 0; //min delay 

fork 

begin : ok 

@(negedge Wires. XACK) Data = - Wires.DAT; 

EndRead ( ) ; 

@(posedge Wires. XACK) Error = 0; 
disable timeout; 
end 

begin: timeout // Timeout if no acknowledgement 
#900 Error = 1; 

EndRead ( ) ; 
disable ok; 
end 
join 

FreeBus ( ) ; 

endtask 

task Tasks. WriteMem (input logic [19:0] Address, 

input logic [15:0] Data, 

output bit Error) ; 

if (Master_State == IDLE) GetBusO; 

else assert (MasterjState == READY) ; 

MasterjState = WRITE; 

Error =1; // default if no slave responds 

GetBus ( ) ; 

adr = -Address; 

dat = -Data; 

#50 mwtc = 0; 
fork 

begin : ok 

@ (negedge Wires . XACK) EndWrite ( ) ; 

@(posedge Wires. XACK) Error = 0; 
disable timeout; 
end 
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begin: timeout // Timeout if no acknowledgement 
#900 Error = 1; 

EndWrite ( ) ; 

disable ok; 
end 
join 

FreeBus ( ) ; 

endtask 

task EndRead ( ) ; 
mrdc = 1; 

#50 adr = ' z; 

endtask 

task EndWrite (); 
mwtc = 1; 

#60 adr = 1 z; 
dat = ' z ; 

endtask 

task GetBus ( ) ; 

©(negedge Wires. BCLK) breq = 0; 
cbrq = 0; 

@(negedge Wires .BPRN [Number] ) ; 

@(negedge Wires. BCLK iff ! Wires .BPRN [Number] ) ; 

#50 busy = 0; 
cbrq = 1; 

endtask 

task FreeBus ( ) ; 
breq = 1; 

if (Wires. CBRQ) Master_State = READY; 
else begin 

Master__State = IDLE; 

busy =1; // relinquish the bus if CBRQ asserted 

end 

endtask 

endmodule: MultibusMaster 



module Tester (interface 
logic [15:0] D 
logic E 

int A 



Bus) ; // repeated from previous example 
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initial begin 

for (A = 0; A < 21 1 hlOOOOO ; A = A + 21'h40000) 

begin 

fork #1000; Bus.WriteMem(A[19:0] , 0, E) ; join 

if (E) $display ("%t bus error on write %h", $time, A); 

else $display ("%t write OK %h H , $time, A); 
fork #1000; Bus.ReadMem(A[19:0] , D, E) ; join 
if (E) $display ("%t bus error on read %h", $time, A); 
else $display ("%t read OK %h", $time, A); 

end 

end 

initial # 10000 $finish; 

endmodule 



module Mult ibusArbi ter (interface Bus) ; 

logic [1 : Bus .MASTERS] bprn = '1; assign Bus.BPRN = bprn; 
int last = 0; 

always @(negedge Bus.BCLK) 

if (Bus . CBRQ == 0) begin // request 
automatic int i = last+1; 
forever begin 

if (i > Bus. MASTERS) i = 1; 
if (Bus .BREQ [i] == 0) break; 

assert (i != last); else $fatal(0, "no bus master"); 

i++; 

if (i > Bus. MASTERS) i = 1; 

end 

last = i; 

#50 bprn /* [i] */ = 0; $display ( "bprn [%b] = %b", i, bprn) -; 

end 

else if (Bus. BUSY == 0) begin // relinquish 
#50 bprn /* [last] */ = 1; 

end 

endmodule : Mult ibusArbi ter 



module MultibusMonitor (interface Bus) ; 
initial $monitor( 

"ADR=%h DAT=%h MRDC«%b MWTC=%b XACK=%b BREQ=%b CBRQ=%b 
BUSY=%b BPRN=%b", 

Bus. ADR, Bus. DAT, Bus.MRDC, Bus.MWTC, Bus.XACK, 

Bus. BREQ, Bus. CBRQ, Bus. BUSY, Bus.BPRN); 

endmodule 
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// Memory Module with pin level interface 
module Memory PIN ( 



input 


[19:0] 


ADR # 


// 


address bus 


inout 


[15:0] 


DAT, 


// 


data bus 


input 


/*active0*/ 


MRDC, 


// 


memory read 


input 


/*active0*/ 


MWTC, 


// 


memory write 


output 


logic /*active0*/ 


XACK, 


// 


acknowledge 



input CCLK 

) ; 

parameter Lo = 20'hOOOOO; 
parameter Hi = 20'h3ffff; 
logic [15:0] Mem[Lo:Hi] ; 
logic [15:0] Bufdat; 

logic Bufena = 0; //default disables buffers 

initial XACK = 1/ // default disables 

assign DAT = Bufena ? Bufdat : ' z; 

always @(posedge CCLK) 
begin 

automatic logic [19:0] Address = -ADR; 
if (MRDC == 0 && Address >= Lo && Address <= Hi) 

begin 

Bufdat <= -Mem [Address] ; 

Bufena <= 1; 

XACK <= 0; 

end 

else if (MWTC == 0 && Address >= Lo && Address < 

begin 

Mem [Address] = -DAT; 

XACK <= 0; 

end 

else begin 

XACK <= 1; 

Bufena <= 0; 

end 
end 



// read 



= Hi) 

// write 



endmodule : Memory PIN 
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11.6.2 Adapter in an interface 

Another way to code adapters is to put them in the interface. This is 
straightforward for a single adapter, but not for multiple ones, 
because of name collisions. 

These require modified versions of the interface, which is quite 
easy for master adapters, since unused tasks should not interfere 
with the model. Slave adapters, on the other hand, call tasks or 
functions in the slave TLM, and there will be an elaboration error if 
the slave TLM is missing. So a different version of the interface is 
needed. The example below shows a master adapter. 

Example 11-7: Simple Multibus TLM example with master adapter as an interface 
module TopInterfaceAdapter; 

Multibus Mbus(); 

Tester T(Mbus) ; 

Mult ibusArbi ter MA(Mbus) ; 

Clock Clk(Mbus); 

MultibusMonitor MO (Mbus); 

/* MemoryPIN # ( .Lo (20 ’hOOOOO) , .Hi (20 ' h3f f f f ) ) Ml (Mbus); 
MemoryPIN # ( .Lo (20 'h40000) , .Hi (20 ' h7f f f f ) ) M2 (Mbus); */ 

MemoryPIN #( .Lo (20 'hOOOOO) , .Hi (20 » h3f f f f ) ) Ml (Mbus . ADR # 

Mbus .DAT, Mbus. MRDC, Mbus.MWTC, Mbus. XACK, Mbus.BCLK) ; 
MemoryPIN # ( .Lo (20 'h40000) , .Hi (20 ' h7f f f f ) ) M2 (Mbus .ADR, 

Mbus . DAT , Mbus . MRDC , Mbus . MWTC , Mbus . XACK , Mbus . BCLK) ; 

endmodule : TopInterfaceAdapter 



// Interface header 
interface Multibus; 

parameter int MASTERS =1; // number of bus masters 



parameter int Number ~ i ; 

// structural communication 
tri [19:0] 
tri [15:0] 

wand /*active0*/ MRDC, 

wand /*active0*/ 

wand /*active0*/ [1 : MASTERS] 



ADR; // address bus 

DAT; // data bus 

MWTC; // mem read/write commands 

XACK; // acknowledge 

BREQ ; 
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wand /*active0*/ 


CBRQ 


wire /*active0*/ 


BUSY 


wire /*active0*/ 


[1 .-MASTERS] BPRN 


logic 


BCLK 


logic 


CCLK 


wand 


INIT; 



// Master Adapter converts ReadMem/WriteMem calls into waveforms 
enum { IDLE, READ, WRITE} Master_State; 

logic [19:0] adr = ' z; assign ADR = adr; 

logic [15:0] dat = ' z; assign DAT = dat; 

logic mrdc = 1; assign MRDC = mrdc; 

logic mwtc = 1; assign MWTC = mwtc; 

logic breq = 1; assign BREQ [Number] = breq; 

logic cbrq = 1; assign CBRQ = cbrq; 

task ReadMem (input logic [19:0] Address, 

output logic [15:0] Data, 

output bit Error) ; 

assert (Master_State == IDLE) ; 

Master__State = READ; 

Data = 'x; 

Error =1; // default if no slave responds 

GetBus ( ) ; 

adr = -Address,- 

#50 mrdc = 0; //min delay 

fork 

begin: ok 

@(negedge XACK) Data = - DAT; 

EndRead ( ) ; 

@(posedge XACK) Error = 0; 
disable timeout; 
end 

begin: timeout // Timeout if no acknowledgement 
#900 Error = 1; 

EndRead ( ) ; 

disable ok; 
end 
join 

FreeBus ( ) ; 

MasterJState = IDLE; 

endtask 

task WriteMem (input logic [19:0] Address, 

input logic [15:0] Data, 

output bit Error) ; 
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assert (Master_State == IDLE) ; 

Master_State = WRITE; 

Error =1; // default if no slave responds 

GetBus ( ) ; 

adr = -Address; 

dat = -Data; 

#50 mwtc = 0; 
fork 

begin : ok 

@(negedge XACK) EndWriteO; 

©(posedge XACK) Error = 0; 
disable timeout; 
end 

begin: timeout // Timeout if no acknowledgement 
#900 Error = 1; 

EndWrite () ; 
disable ok; 
end 
join 

FreeBus ( ) ; 

Master_State = IDLE; 

end task 

task EndRead ( ) ; 
mrdc = 1; 

#50 adr = 'z; 

endtask 

task EndWrite ( ) ; 
mwtc = 1; 

#60 adr = ' z; 
dat = ' z ; 

endtask 

task GetBus ( ) ; 
breq = 0; 
cbrq = 0; 

@ (negedge BCLK iff ! BPRN [Number] ) ; 

#50 busy « 0; 
cbrq = 1; 

endtask 

task FreeBus ( ) ; 
breq = 1; 
busy = 1; 

endtask 



endinterface 
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module Clock (Multibus Bus) ; 

always begin // clock 
#50 Bus . BCLK = 0; 

#50 Bus. BCLK = 1; 

end 

initial # 10000 $finish; 
endmodule : Clock 



module Tester (interface Bus) ; 
logic [15:0] D; 
logic E; 
int A; 

initial begin 

for (A = 0; A < 21 1 hlOOOOO ; A = A + 21'h40000) 

begin 

fork 

# 1000 / 

Bus . WriteMem (A [19 : 0] , 0, E) ; 

join 

if (E) $display ("%t bus error on write %h" f $time, A) ; 

else $display ("%t write OK %h" , $time, A); 
fork 
# 1000 ; 

Bus . ReadMem ( A [ 1 9 : 0 ] , D, E) ; 
join 

if (E) $display ("%t bus error on read %h", $time / A) / 
else $display ("%t read OK %h", $time # A) ; 

end 

end 

endmodule 



module MultibusArbiter (interface Bus) ; 

logic [1: Bus. MASTERS] bprn = '1; assign Bus.BPRN = bprn; 
logic busy = 1; assign Bus. BUSY = busy; 
int last = 1; 

always @(posedge Bus. BCLK) 

if (Bus . CBRQ == 0 ScSt Bus. BUSY == 1) begin // request 
automatic int i = last+1; 
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forever begin 

if (i > Bus. MASTERS) i = 1; 
if (Bus.BREQ[i] == 0) break; 

assert (i != last); else $fatal(0 / "no bus master"); 

i++; 

if (i > Bus. MASTERS) i = 1; 

end 

last = i; 

#50 busy = 0; 

#50 bprn /* [i] */ = 0; $display ( "bprn [%b] = %b", i, bprn); 

end 

else if (Bus .BREQ [last] == 1) begin // relinquish 
#50 bprn /* [last] */ = 1; 

#50 busy = 1; 

end 

endmodule : MultibusArbiter 



module Mult ibusMoni tor (interface Bus) ; 
initial $monitor( 

"ADR=%h DAT=%h MRDC=%b MWTC=%b XACK=%b BREQ=%b CBRQ=%b 
BUSY=%b BPRN=%b" , 

Bus. ADR # Bus. DAT, Bus.MRDC, Bus.MWTC, Bus.XACK, Bus. BREQ, 
Bus . CBRQ , Bus. BUSY, Bus. BPRN); 

endmodule 



// Memory Module with pin level interface 



module MemoryPIN ( 
input [19:0] 
inout [15:0] 
input /*active0*/ 
input /*active0*/ 
output logic /*active0* 
input 



ADR, 


// 


address bus 


DAT, 


// 


data bus 


MRDC, 


// 


memory read 


MWTC, 


// 


memory write 


XACK, 

CCLK 


// 


acknowledge 



parameter Lo = 20'h00000; 
parameter Hi = 20'h3ffff; 
logic [15:0] Mem[Lo:Hi] ; 
logic [15:0] Bufdat; 

logic Bufena = 0; //default disables buffers 



initial XACK =1; // default disables 
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assign DAT = Bufena ? Bufdat : ' z; 

always @(posedge CCLK) begin 

automatic logic [19:0] Address = -ADR; 

if ( MRDC == 0 && Address >= Lo && Address <= Hi) // read 

begin 

Bufdat <= -Mem [Address] ; 

Bufena <= 1; 

XACK <= 0; 

end 

else if (MWTC == 0 && Address >= Lo && Address <= Hi) 
begin // write 

Mem [Address] = -DAT; 

XACK <= 0; 

end 

else begin 

XACK <= 1; 

Bufena <= 0; 

end 

end 

endmodule : MemoryPIN 



11.7 More complex transactions 



The transactions modeled above are simple, in the sense that there 
is only one at a time. This allows the lifetime of the transaction to 
correspond to the lifetime of the task call initiating it. The task can 
contain the data relevant to the transaction, such as start time. 

Other systems may allow one transaction to start before the previ- 
ous one has finished (overlapping or pipelining). They may even 
allow out-of-order completion (split transactions). In these cases, 
the data about the transaction cannot be contained in a single task. 
Either a new process (thread) must be spawned to control or moni- 
tor the transaction and to hold relevant data, or a dynamic data 
object must be created to store the information about the transac- 
tion. 
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These more elaborate transaction level models and their language 
constructs are typically used in verification, and are therefore 
described in the forthcoming companion book, SystemVerilog for 
Verification . 



11,8 Summary 



Transactions have traditionally been used in system modeling and 
in hardware verification. TLM has not been used much by hardware 
designers. One of the reasons is that Verilog-2001 and VHDL-2000 
do not have the ability to define an interface with methods, whereas 
some programming and verification languages have classes, which 
can be used in a similar way. 

SystemVerilog brings the interface and method constructs into 
HDL, allowing the hardware designer to take advantage of the 
TLM technique, and to represent the rest of the system at a more 
abstract level, with the benefits of simplicity and simulation perfor- 
mance. 

Over time, new tools are likely to be developed for verification (and 
maybe for synthesis) of the transaction level modeling style pre- 
sented in this chapter. 




Appendix A 

The System Verilog Formal 
Definition (BNF) 



This appendix contains the formal definition of the SystemVerilog 

standard. The definition is taken directly from Annex A of the Sys- 
tem Verilog Language Reference Manual (SystemVerilog LRM) . 

The formal definition of SystemVerilog is described in Backus- 

Naur Form (BNF). The variant used in this appendix is as follows: 

• Bold text represents literal words themselves (these are called 
terminals). For example: module. 

• Non-bold text (possibly with underscores) represents syntactic 
categories (i.e. non terminals). For example: portidentifier. 

• Syntactic categories are defined using the form: 

syntactic_category ::= definition 

• A vertical bar ( | ) separates alternatives. 

• Square brackets ( [ ] ) enclose optional items. 

• Braces ( { } ) enclose items which can be repeated zero or more 
times. 



1. The SystemVerilog formal definition is reprinted with permission from the SystemVerilog 
3.1 a/draft 2 Language Reference Manual. Copyright 2003 by Accellera. This draft version 
was a work-in-progress and had not been ratified by the Accellera standards organization. 
See page xxvii in the Preface for information on obtaining the latest released version of the 
SystemVerilog Language Reference Manual. 
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A.1 Source text 
A.1.1 Library source text 

library_text ::= { library_descriptions } 
library_descriptions ::= 
library_declaration 
| include__statement 
| config_declaration 
library_declaration ::= 

library library_identifier file_path_spec { , file_path_spec } 

[ -incdir file_path_spec { , file_path_spec } ] ; 
file_path_spec ::= file_path 
include_statement ::= include file_path_spec ; 

A.1. 2 Configuration source text 

config declaration 

con fig configjdentifier ; 
design_statement 
{ config_rule_statement } 
end con fig 

design__statement design { [ library_identifier . ] celljdentifier } ; 
configrulestatement ::= 

defaultclause liblistclause 
| inst_clause liblist_clause 
| inst__clause use_clause 
| cell clause liblist_clause 
| cell_clause use_clause 
default_clause ::= default 
inst clause ::= instance inst_name 
inst_name topmodulejdentifier { . instance Jdentifier } 

cell_clause ::= cell [ library_identifier . ] celljdentifier 
liblist clause liblist {library Jdentifier} 
use_clause ::= use [ library identifier . ] celljdentifier [ : config ] 

A.1. 3 Module and primitive source text 

source Jext ::= [ timeunits declaration ] { description } 
description ::= 

module_declaration 
| udp declaration 
| interface declaration 
| program_declaration 
| package_declaration 
| { attribute_instance } package Jtem 
| { attributejnstance } bind_directive 
| { attribute_instance } ; 
module_nonansi_header 

{ attributejnstance } module keyword [ lifetime ] modulejdentifier [ parameter_port Jist ] 
list_of_ports ; 
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module_ansi_header ::= 

{ attribute_instance } modulejceyword [ lifetime ] module_identifier [ parameter_portJist ] 
[ list_of_port_declarations ] ; 
module_declaration 

module_nonansi_header [ timeunits_declaration ] { modulejtem } 
end mod tile [ : modulejdentifier ] 

| module_ansi_header [ timeunits_declaration ] { non_port_moduleJtem } 
end module [ : module identifier ] 

| { attribute_instance } module_keyword [ lifetime ] module identifier ( .* ) ; 

[ timeunits_declaration ] { modulejtem } eiidmodule [ : module identifier ] 

| extern module_nonansi_header 
| extern module_ansi_header 
module keyword module | macromodule 
interface_nonansi_header 

{ attribute_instance } interface [ lifetime ] interface identifier 
[ parameter_port_list ] list_of_ports ; 
interface_ansi_header ::= 

{attribute_instance } interface [ lifetime ] interfaceidentifier 
[ parameter_port_list ] [ list_of_po redeclarations ] ; 
interface_declaration ::= 

interface_nonansiheader [ timeunits_declaration ] { interface_item } 
endinterface [ : interface_identifier ] 

| interface_ansi_header [ timeunitsdeclaration ] { non_port JnterfaceJtem } 
endinterface [ : interface_identifier ] 

| { attribute_instance } interface interfacejdentifier ( .* ) ; 

[ timeunits_declaration ] { interface_item } 
endinterface [ : interfacejdentifier ] 

| extern interfacenonansijieader 
| extern interface_ansi_header 
program_nonansi_header ::= 

{ attributejnstance } program [ lifetime ] programjdentifier 
[ parameter jjortJist ] list_of_ports ; 
program_ansi_header 

{attributejnstance } program [ lifetime ] programjdentifier 
[ parameter _portJist ] [ list_of_port_declarations ] ; 
program_declaration ::= 

program_nonansi_header [ timeunits_declaration ] { program Jtem } 
end program [ : programjdentifier ] 

| program_ansi_header [ timeunits_declaration ] { non_port_program item } 
endprogram [ : programjdentifier ] 

| { attributejnstance } program programjdentifier ( .* ) ; 

[ timeunits_declaration ] { program item } 
endprogram [ : programjdentifier ] 

| extern program nonansi header 
| extern program_ansi_header 
class declaration ::= 

[ virtual ] class [ lifetime ] classjdentifier [ parameter jportjist ] 

[ extends classjdentifier [ parameter_value_assignment ] ] ; { classjtem } 
endclass [ : classjdentifier] 
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package__decIaration 

{ attribute_instance } package package Jdentifier 
[ timeunits_declaration ] { { attributejnstance } package_item } 
endpackage [ : packagejdentifier ] 
timeunits_declaration ::= 

tinieti nit timejiteral ; 

| timepiecision timejiteral ; 

| timcunit timejiteral ; 

timepi ecision timejiteral ; 

| timepi ecision timejiteral ; 
tiineunit timejiteral ; 

A.1.4 Module parameters and ports 

parameter_portlist 

# ( list_of_param_assignments { , parameter_port_declaration } ) 
| # ( parameter_port_declaration { , parameter_port_declaration } ) 
parameter_port_declaration ::= 
parameter_declaration 
| datajype Iist_of_param_assignments 
| type list_ofjype_assignments 
list_of_ports ( port { , port } ) 
list_of_port__declarations 

( [ ansi_port_declaration { . ansi_port_declaration } ] ) 
non_generic_port_declaration ::= 

{ attributejnstance } inout declaration 
| { attributejnstance } input_declaration 
| { attributejnstance } output_declaration 
| { attributejnstance } redeclaration 
| { attributejnstance } interface_port_declaration 
port ::= 

[ portexpression ] 

| . port Jdentifier ( [ port_expression ] ) 
port_expression 

port_reference 

| { port_reference { , port ^reference } } 
port reference 

port Jdentifier [ | constant_range_expression | ] 
port_declaration ::= 

non_generic_port_declaration 
| { attributejnstance } genericJnterface_j>ort_declaration 
ansi_port_declaration 
port_declaration 

I port_type list_of_portJdentifiers 
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A.1.5 Module items 

modulecommonitem ::= 

module_or_generate_item_declaration 
| interfacejnstantiation 
| programjnstantiation 
| concurrentassertionjtem 
| bind_directive 
| continuous_assign 
| net_alias 
| initialconstruct 
| final_construct 
| always_construct 
| combinational_construct 
| latch_construct 
| ff_construct 

I; 

modulejtem 

non_generic_port_declaration ; 

| non_port_module_item 
module_or_generate_item ::= 

{ attribute_instance } parameter_override 
| { attributejnstance } gate_instantiation 
| { attributejnstance } udp instantiation 
| { attributejnstance } modulejnstantiation 
| { attributejnstance } module_common item 
module_or_generate Jtem_declaration : := 

package_or_generateitem_declaration 
| genvar declaration 
| clocking_decl 

| default clocking clocking identifier ; 
non_port_moduleJtem ::= 

generated jnoduleinstantiation 
| moduIe_or_generate_item 
| specify_block 

| { attributejnstance } specparam_declaration 
| program_declaration 
| module_declaration 
| timeunits_declaration 1 9 

parameter override ::= defparam list_of_defparam_assignments ; 
bind__directive ::= 

bind module Jdentifier bindjnstantiation ; 

| bind name_ofJnstance bindjnstantiation ; 
bindjnstantiation ::= 

program_instantiation 
| modulejnstantiation 
| interfacejnstantiation 
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A.1.6 Interface items 

interface_or_generateitem ::= 

{ attributejnstance } modulecommonjtem 
| { attribute_instance } modport_declaration 
| { attribute_instance } extern Jf_declaration 
extemtf_declaration ::= 

extern method_prototype 
| extern forkjoin task named_task_proto ; 
interface_item ::= 

non_generic_port_declaration ; 

| non_portinterfaceitem 
non_portinterfaceJtem 

generatedjnterfaceinstantiation 
| { attributejnstance } specparam_declaration 
| interface_or_generate_item 
| program_declaration 
| interface__declaration 
| timeunits_declaration 1 9 

A. 1.7 Program items 

programitem 

portdeclaration ; 

| non_port_program_item 
non_port_programitem ::= 

{ attributejnstance } continuousassign 
| { attribute_instance } module_or_generate_item_declaration 
| { attributejnstance } specparam_declaration 
| { attribute_instance } localj3arameter_declaration 
| { attribute instance } parameter_declaration ; 

| { attribute_instance } initial_construct 
| { attributejnstance } concurrent__assertion_item 
| { attributejnstance } timeunits_declaration 1 9 
| class_declaration 

A. 1.8 Class items 

class Jtem ::= 

{ attributejnstance } class_property 
| { attribute_instance } class_method 
| { attribute_instance } class_constraint 
| { attribute instance } type declaration 
| { attribute_instance } class_declaration 
| { attribute__instance } timeunits_declaration 1 9 
class_property ::= 

{ property_qualifier } data_declaration 

| const { classjtem_qualifier } data_type constjdentifier [ = constant expression ] ; 
class_method ::= 

{ method qualifier } task_declaration 
| { method qualifier } function declaration 
| extern { method_qualifier } method_prototype 
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class_constraint ::= 

constraint_prototype 
| constraint_declaration 

class_item_qualifier 8 ::= 
static 

| protected 
| local 

property_qualifier 8 ::= 
rand 
| randc 

| class_item_qualifier 

method_qualifier 8 ::= 
virtual 

| class_item_qualifier 
method_prototype ::= 

task named_task_proto ; 

| function named_fimction__proto ; 
extem_method_declaration ::= 

function [ lifetime ] class identifier :: functionjjodydeclaration 
| task [ lifetime ] class Jdentifier :: task_body_declaration 

A. 1.9 Constraints 

constraint_declaration ::= [ static ] constraint constraint Jdentifier { { constraint_block } } 
constraint_block ::= 

solve identifierjist before identifierjist ; 

| constraint_expression 
constraint_expression ::= 
expression ; 

| expression -> constraint_set 
| if ( expression ) constraint_set [ else constraint_set ] 

| expression dist { distjist } ; 

| foreach ( array_identifier f loop variables ] ) constraint_set 
constraint set ::= 

constraint_expression 
| { { constraint_expression } } 
distjist ::= distjtem { , dist item } 
dist_item ::= 

value_range := expression 
| value_range :/ expression 

constraint_prototype ::= [ static ] constraint constraint identifier 
extem_constraint__declaration ::= 

[ static ] constraint class_identifier :: constraint_identifier { { constraint_block } } 
identifierjist identifier { , identifier } 
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A.1.10 Package items 

package_item ::= 

package_or_generate_item_declaration 
| specparamdeclaration 
| concurrent_assertion_item_declaration 
| anonymous_program 
| timeunits_declaration 19 
package_or_generate_item_declaration : := 
net_declaration 
| data declaration 
| taskdeclaration 
| function_declaration 
| dpi_import_export 
| extem_constraint_declaration 
| extem_method_declaration 
| class_declaration 
| parameterdeclaration ; 

| local_parameter_declaration 
| covergroup_declaration 
| overload_declaration 

anonymous_program ::= program ; { anonymous_program_jtem } endprograni 
anonymous_program_item ::= 
taskdeclaration 
| flinction declaration 
| class_declaration 
| covergroup_declaration 

A.2 Declarations 

A.2.1 Declaration types 

A.2.1.1 Module parameter declarations 

local_parameter_declaration 

localparain [ signing ] { packed_dimension } list_of_param_assignments ; 
| localparain datatype list_ofjparam_assignments ; 
parameter_declaration 

parameter [ signing ] { packed_dimension } list_of_param_assignments 
| parameter data_type list_of_param_assignments 
| parameter type list_of_type_assignments 
specparam_declaration 

speeparam [ packed_dimension ] list_of_specparam_assignments ; 

A.2.1 .2 Port declarations 

inout_declaration ::= 

inout [ port_type ] list_of_port_identifiers 
input__declaration 

input [ port_type ] list_of_port_identifiers 
| input data_type list of variable identifiers 
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outputdeclaration ::= 

output [ port_type ] list_of_port_identifiers 
| output data type Iist_of_variable_port_identifiers 
interface_port_declaration ::= 

interface_identifier list_of_interface_identifiers 
| interface_identifier . modport_identifier list_of_interface_identifiers 
ref_declaration ref data Jype list_of_port_identif!ers 

genericinterface_port_declaration : := 

i n terfaee list of interface identifiers 
| interface . modport_identifier list_ofJnterfaceJdentifiers 

A.2.1.3 Type declarations 

data_declaration 16 ::= 

[ const ] [ lifetime ] variabledeclaration 
| type_declaration 
| package_import_declaration 
| virtual interface declaration 
package_import_dec!aration ::= 

import package Jmport item { , package Jmport item } ; 
package import Jtem ::= 

package identifier :: identifier 
| package Jdentifier :: * 

genvar_declaration ::= genvar list_of_genvar_identifiers ; 
net_declaration 15 ::= 

net type oMrireg [ drive_strength | chargestrength ] [ vectored | sea la red ] 

[ signing ] { packed dimension } [ delay3 ] list_of_net_decl_assignments ; 
type declaration ::= 

typed el datatype type_identifier variable__dimension ; 

| typedef interfacejnstancejdentifier . type_identifier type_identifer ; 

| typedef [ enum | struct | union | class ] typejdentifier ; 
variable_declaration ::= 

datatype list of variable decl assignments ; 
lifetime static | automatic 

A.2.2 Declaration data types 
A.2.2.1 Net and variable types 

casting_type ::= simple_type | size | signing 
data_type_common_item ::= 

integer_vector_type [ signing ] { packed_dimension } 

| integer_atom_type [ signing ] 

| typejdentifier { packed_dimension } 

| non integer type 

| struct_union [ packed [ signing ] ] { struct__union_member { stract unionjnember } } 
{ packed_dimension } 14 

| enum [ enum_base_type ] { enum_name_declaration { , enum_name_declaration } } 

I string 
| chandle 
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| virtual [ interface ] interface_identifler 
datatype ::= 

data_type_common_item 
| event 

| class_scope_type_identifier 
| covergroupjdentifier 
enum_base_type ::= 

integer_atom_type [ signing ] 

| integer_vector_type [ signing ] [ packed dimension ] 
enum_name_declaration enumidentifier [ | constant_range_expression | ] [ = constant expression ] 
class__scope_type_identifier: := 

class_scope [ :: type_identifier ] 
classscope ::= 

class_identifier [ parameter_value_assignment ] 

{ :: class identifier [ parameter_value_assignment ] } 
integer_type ::= integer_vector_type | integer_atom_type 
integer_atom_type ::= byte | shortint | int | longint | integer 
integer_vector_type ::= bit | logic | reg 
non_integer_type ::= time | sliortreal | real | realtime 

net__type supplyO | supply! | tri | triand | trior | triO | tril | wire | wand | wor 
portjype ::= 

data_type 

| net Jype_or_trireg [ signing ] { packed_dimension } 

| [ signing ] { packed_dimension } 
net_type_ or _tri r eg ::= net_type | tri reg 
signing ::= signed | unsigned 

simplejype ::= integertype | non_integer_type | type_identifier 
struct_union_member ::= 

{ attribute instance } data_type { packed_dimension } 

variable_identifier variable_dimension { , variable_identifier variable__dimension } ; 
struct__union ::= struct | union 

A.2.2.2 Strengths 

drive strength 

( strengthO , strength 1 ) 

| ( strength 1 , strengthO ) 

| ( strengthO , highzl ) 

| ( strength 1 , highzO ) 

| ( highzO , strength 1 ) 

| ( highzl , strengthO ) 

strengthO ::= supplyO | strongO | pul 10 | weakO 
strengthl supply] | strong! | pull 1 | weakl 
charge_strength ::= ( small ) | ( medium ) | ( large ) 

A.2.2.3 Delays 

delay3 ::= # delay_value 

| # ( mintypmax_expression [ , mintypmax_expression [ , mintypmax_expression ] ] ) 
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delay2 ::= # delay_value | # ( mintypmaxexpression [ , mintypmaxexpression ] ) 
delay_value ::= 

unsigned_number 
| real number 
| identifier 

A.2.3 Declaration lists 

lis^of defparam^ssignnient 8 ::= defparam_assignment { , defparam_assignment } 
list of genvar identifiers genvar Jdentifier { , genvarjdentifier } 
list_of_interface_identifiers ::= interface_identifier { unpacked_dimension } 

{ , interfaceidentifier { unpacked_dimension } } 
list__of_modport_port_identifiers port_identifier { , portjdentifier } 

| . portjdentifier ( [ expression ] ) { . portjdentifier ( [ expression ] ) } 
list_ofnet_decl_assignments ::= net_decl_assignment { , net_decl_assignment } 
list_of_netJdentifiers ::= netjdentifier { unpacked_dimension } 

{ , netjdentifier { unpackeddimension } } 
list_of_param_assignments ::= param_assignment { , param_assignment } 
list_of_portJdenti filers portjdentifier { unpacked_dimension } 

{ , portjdentifier { unpacked__dimension } } 

I • portjdentifier ( [ expression ] ) { . portjdentifier ( [ expression ] ) } 
list_of_udp_port identifiers portjdentifier { , portjdentifier } 
list_of_specparam_assignments ::= specparam_assignment { , specparam_assignment } 
list_oftf_variableidentifiers ::= portjdentifier variable_dimension [ = expression ] 

{ . portjdentifier variable_dimension [ = expression ] } 
list_ofjype_assignments ::= type_assignment { , type_assignment } 

list_of_variable_decl_assignments ::= variable_decl_assignment { . variable_decl_assignment } 
list__of_variableJdentifiers ::= variable Jdentifier variable_dimension 
{ , variable Jdentifier variable_dimension } 

list_of_variable_port identifiers ::= portjdentifier variable_dimension [ = constant_expression ] 
{ * portjdentifier variable_dimension [ = constant_expression ] } 
list__of_virtual Jnterface_decl : := 

variableidentifier [ = interfacejnstance_identifier ] 

{ , variablejdentifier [ = interfacejnstancejdentifier ] } 

A.2.4 Declaration assignments 

defparam assignment ::= hierarchical_parameter Jdentifier = constant_mintypmax_expression 
net_decl_assignment ::= netjdentifier { unpacked_dimension } = expression 
param_assignment ::= parameter Jdentifier = constantjparam_expression 
specparam_assignment ::= 

specparamjdentifier = constant_mintypmax_expression 
| pulse_control_specparam 
type^ssignment type Jdentifier = datajype 

pulse_control_specparam ::= 

PATH PULSES = ( reject Jimit__value [ , error limit_value ] ) ; 

| PATH PU LSE$specify_inputJeiminal_descriptor$specify_outputJerminal_descriptor 
= ( rejectjimit_value [ , errorJimit_value ] ) ; 
error Jimit_value limit_value 
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reject_limit_value ::= limit_value 
limit_value ::= constant_mintypmax_expression 
variable_decl_assignment ::= 

variable ^identifier variable_dimension [ = expression ] 

| variable_identifier 1 1 = new [ expression ] [ ( variable identifier ) ] 

| class_variable_identifier = new [ ( list_of_arguments ) ] 

| [ covergroup_variable_identifier ] = new [ ( list_of_arguments ) ] 17 

A.2.5 Declaration ranges 

unpacked_dimension ::= | dimension_constant_expression : dimension_constant_expression j 
| | dimensionconstantexpression 1 

packed_dimension 1 2 

| dimension_constant_expression : dimension_constant_expression ] 

| unsized_dimension 

range ::= [ msb_constant_expression : lsb_constant_expression 1 
associativedimension ::= 

| datatype | 

11*1 

variable__dimension 13 

{ sized_or_unsized_dimension } 

| associative dimension 

unsized_dimension 12 ::= [] 

sized_or_unsized_dimension ::= unpackeddimension | unsized_dimension 

A.2.6 Function declarations 

function_data_type 6 

datatypecommonitem 
| void 

function_body_declaration ::= 

[ signing ] [ type_or_dimensions ] 

[ interface_identifier . ] function_identifier ; 

{ tf_item__declaration } 

{ function statement or null } 
endfunction [ : function_identifier ] 

| [ signing ] [ type_or_dimensions ] 

[ interfacejdentifier . ] function_identifier ( [ tf_port_list ] ) ; 

{ block_item_declaration } 

{ function_statement_or_null } 
endfunction [ : function ^identifier ] 
function_declaration ::= 

function [ lifetime ] function_body_declaration 

named_function_proto: := [ signing ] functiondatatype function_identifier ( [ list_of_tf_proto_formals ] ) 
list__of_tf_proto_formals ::= 

{ attributeinstance } tf_proto_formal { , { attribute instance } tf_proto_formal } 
type_or_dimensions 

packed_dimension { packed_dimension } 

| function_data_type 
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dpi_import_export ::= 

import "DPI" [ dpi importj>roperty ] [ c identifier = ] dpi function_proto ; 

| export "DPI" [ cjdentifier = ] function function_identifier ; 
dpiimport_property ::= context | pure 
dpiJunction_proto 9,10 ::= function named_function_proto 

A.2.7 Task declarations 

task_body_declaration ::= 

[ interface_identifier . ] taskjdentifier ; 

{ tfjtemdeclaration } 

{ statement_or_null } 
endtask [ : taskjdentifier ] 

| [ interfacejdentifier . ] taskjdentifier ( [ tf_portJist ] ) ; 

{ block Jtemdeclaration } 

{ statement_or_null } 
endtask [ : taskjdentifier ] 

task declaration ::= task [ lifetime ] task__body_declaration 
tfjtemdeclaration ::= 

block_item_declaration 
| { attributejnstance } tfJnput_declaration ; 

| { attributejnstance } tf_output_declaration ; 

| { attributejnstance } tfJnout_declaration ; 

| { attribute_instance } tf_ref_declaration ; 
tf_port list ::= 

tf_port Jtem { , tf_portJtem } 
tf_portJtem ::= 

{ attributejnstance } tf input_declaration 
| { attribute_instance } tf_output_declaration 
| { attribute_instance } tfJnout_declaration 
| { attributejnstance } tf_ref_declaration 

| { attributejnstance } [ signing ] { packed_dimension } list_of tf_variablejdentifiers 
| { attribute_instance } data type list_of tf_variable_identifiers 
tfJnput_declaration ::= 

input [ signing ] { packed_dimension } Iist_ofJf_variableJdentifiers 
| input datajype listofjfvariablejdentifiers 
tf_output_declaration 

output [ signing ] { packed_dimension } list_ofJf_variableJdentifiers 
| output datajype list_of_tf_variable identifiers 
tf inout_declaration 

in out [ signing ] { packeddimension } Hst_ofJf_variableJdentifiers 
| inout data_type list_ofJf_variableJdentifiers 
tf ref declaration 

[ const ] ref datajype list_ofJf_variableJdentifiers 
named Jask__proto taskjdentifier ( [ list_of tf_proto_formals ] ) 

tf_proto_formal ::= 

tfJnput_declaration 
| tfoutputdeclaration 
| tf_inout_declaration 
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| tf_ref_declaration 

A.2.8 Block item declarations 

block Jtem_declaration ::= 

{ attribute_instance } data declaration 
| { attribute_instance } local__parameter_declaration 
| { attributejnstance } parameterdeclaration ; 

| { attributejnstance } overload_declaration 
overload_declaration ::= 

bind overload_operator function data type functionjdentifier ( overload_proto_formals ) ; 
overload_operator ::= + 1 ++ 1 - 1 - - 1 * | ** | / 1 % | == | != | < | <= | > | >= | = 
overload_proto_formals ::= data_type {, datatype} 

A.2.9 Interface declarations 

virtual Jnterface_declaration ::= 

virtual [ interface ] interface_identifier list_of_virtual_interface_decl ; 
modport_declaration mod port modport_item { , modportitem } ; 

modportjtem ::= modportjdentifier ( modport_ports_decIaration { , modport_ports_declaration } ) 
modport_ports_declaration ::= 

{ attributejnstance } modport_simple_ports_declaration 
| { attributejnstance } modport_hierarchical_ports_declaration 
| { attributejnstance } modportJf_ports_declaration 
| { attributejnstance } modport_clocking_declaration 
modport_clocking_declaration ::= clocking clocking Jdentifier 
modport_simple_ports_declaration ::= 

in put list_of_modport_port identifiers 
| output list_of_modport_port identifiers 
| inout list_of_modport_portJdentifiers 
| ref [ datajype ] list_of_modport_port identifiers 
modport_hierarchical_j)orts_declaration : := 

interfacejnstancejdentifier [ | constant_expression | ] . modport ^identifier 
modportJfjports_declaration ::= 
import_export modportJf_port 
modport Jfjiort 

task named__task_proto { , named_task_proto } 

| function named_function_proto { , named_fiinction_proto } 

| task_or_function identifier { , task_or_function identifier } 
import_export ::= import | export 

A.2.10 Assertion declarations 

concurrent_assertion_item ::= 

concurrent_assert_statement 
| concurrent_cover_statement 
| concurrent_assertion item_declaration 
concurrent_assert_statement 

[blockjdentifier:] assert __property_statement 
concurrent_cover_statement ::= 

[blockjdentifier:] cover_property_statement 
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assert__property_statement: := 

assert property ( property_spec ) action_block 
| assert property ( property ^instance ) action_block 
cover j5roperty_statement: := 

cover property ( property spec ) statementornull 
| cover property ( property_instance ) statement or null 
property_instance ::= 

property_identifier [ ( actualarglist ) ] 
concurrentassertionitemdeclaration : := 
property_declaration 
| sequence_declaration 
property jieclaration 

property property Jdentifier [ property_formalJist ] ; 

{ assertion_variable_declaration } 
property_spec ; 

end property [ : propertyjdentifier] 
property_formalJist ::= 

( formaljistjtem { , formal_listJtem } ) 
property_spec ::= 

[clocking_event ] [ disable iff ] ( expression ) [ not ] property_expr 
| [ disable iff ( expression ) ] [ not ] multi_clock_property_expr 
property_expr 

sequence_expr 

| sequence__expr |-> [ not ] sequence_expr 
| sequenceexpr |=> [ not ] sequence expr 
| ( property_expr ) 
multi_clock_property_expr ::= 
multi_clock_sequence 

| multi_clock_sequence |=> [ not ] multi_clock_sequence 
| ( multi_clock_property_expr ) 
sequence_declaration ::= 

sequence sequence Jdentifier [ sequence_formalJist ] ; 

{ assertion variable declaration } 
sequence_spec ; 

endsequcnce [ : sequencejdentifier ] 
sequence_formal_list ::= 

( formaljistjtem { , formaljistjtem } ) 
sequence_spec ::= 

multi_clock_sequence 
| sequence_expr 
multi_clock_sequence: := 

clocked sequence { ## clocked_sequence } 
clocked_sequence ::= 

clocking_event sequence_expr 
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sequenceexpr ::= 

cycle_delay_range sequence_expr { cycle_delay_range sequence_expr } 

| sequence_expr cycle_delay_range sequence_expr { cycle_delay_range sequence_expr } 
| expression { , variable_assignment } [ boolean abbrev ] 

| ( expression {, variable_assignment } ) [ boolean_abbrev ] 

| sequence_instance [ sequence_abbrev ] 

| ( sequence expr ) [ sequence_abbrev ] 

| sequence_expr and sequence_expr 
| sequence_expr intersect sequence_expr 
| sequence__expr or sequence_expr 
| first_match ( sequence_expr ) 

| expression throughout sequence__expr 
| sequence_expr within sequence_expr 
cycle_delay_range ::= 

## constant_expression 
| ## [ cycle_delay_const_range_expression ] 
sequenceinstance 

sequence_identifier [ ( actual_argjist ) ] 
formal_list_item ::= 

formal_identifier [ = actual_arg_expr ] 
actual_arg_list ::= 

( actual_arg_expr { , actual_arg_expr } ) 

| ( . formaMdentifier ( actual_arg_expr ) { , . formal_identifier ( actual_arg_expr ) } ) 
actual_arg_expr ::= 

event_expression 
boolean_abbrev ::= 

consecutiverepetition 
| non_consecutive_repetition 
| goto_repetition 

sequence_abbrev ::= consecutive_repetition 
consecutive_repetition ::= |* const_or_range_expression | 
non_consecutive_repetition ::=[*= const_or_range_expression | 
goto__repetition ::=!*-> const_or_range_expression | 
const_or_range_expression ::= 
constant_expression 
| cycle_delay_const_range_expression 
cycle_delay_const_range_expression ; := 

constant_expression : constant expression 
| constant_expression : $ 
assertion_variable_declaration ::= 

datajype list_of_variable_identifiers ; 

A.2.11 Covergroup declarations 

covergroup__declaration ::= 

covergroup covergroup_identifier [ ( list_of_tf_proto_formals ) ] [ clocking_event ] ; 

{ coverage_spec_or_option ; } 
endgroup [ : covergroup_identifier ] 
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coveragespecoroption ::= 

{attributejnstance} coverage_spec 
| {attribute_instance} coverage_option 
coverage_option ::= 

option.member identifier = expression 
I type_option.member_identifier = expression 
coverage_spec 

cover jjoint 
| cover cross 

cover_point ::= [ cover_point_identifer : ] coverpoint expression [ iff ( expression ) ] bins_or_empty 
bins_or_empty ::= 

{ {attributejnstance} { bins_or_options ; } } 

I ; 

bins_or_options 

coverage_option 

| [ wildcard ] binsjceyword bin identifier [ | [ expression ] | ] = { range Jist } [ iff ( expression ) ] 
| [ wildcard] binsjceyword binjdentifier [[]] = ( transjist ) [ iff ( expression ) ] 

| binsjceyword binjdentifier [ [ [ expression ] ] ] default [ iff ( expression ) ] 

| binsjceyword binjdentifier default sequence [ iff ( expression ) ] 
binsjceyword: := bins | illegalbins | ignorebins 
range Jist value_range { . value_range } 

transjist ::= trans_set { , trans_set } 

trans_set ::= trans_rangejist => trans_range list { => trans_rangejist } 
trans_rangejist ::= 
transjtem 

| trans item [ { * repeat_range ] ] 

| transjtem [ [ *-> repeat_range ] ] 

| transjtem [ [ *= repeat_range | ] 
transjtem { range Jist } | value_range 
repeat_range 

expression 

| expression : expression 

cover_cross ::= [cover_pointJdentifer : ] cross list_of_coverpoints [ iff ( expression ) ] 
select_bins_or_empty 

list_of_coverpoints ::= cross Jtem , cross Jtem { , cross Jtem } 
cross Jtem ::= 

cover_pointidentifier 
| variablejdentifier 
select J>ins_or_empty ::= 

{ { bins_selections_or_option ; } } 

I; 

bins_selection_or_option 

{ attribute_instance } coverage option 
| { attribute__instance } bins_selection 
bins_selection ::= bins__keyword binjdentifier = select_expression 
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select_expression ::= 
select_condition 
| ! select condition 

| select_expression && select_expression 
| select_expression || select_expression 
| ( selectexpression ) 

select condition binsof ( bins_expression ) [ intersect open range list ] 
bins_expression 

variablejdentifier 

| cover_point_identifier [ . bins_identifier ] 
open_range_list { open_value_range { , open_value_range } } 
open_value_range ::= 
valuerange 
| | expression : $ | 

| | 3 : expression | 

A.3 Primitive instances 

A.3.1 Primitive instantiation and instances 

gate_instantiation ::= 

cmos_switchtype [delay3] cmos_switchJnstance { , cmos_switch_instance } ; 

| enable_gatetype [drive_strength] [delay3] enable_gate_instance { , enable_gate_instance } ; 

| mosswitchtype [delay3] mos_switch_instance { , mos_switch_instance } ; 

| n_input _gatetype [drive_strength] [delay2] n_input_gate_instance { , n_input_gate_instance } ; 

| n_output_gatetype [drive__strength] [delay2] n_output_gate_instance 
{ , n_output _gate_instance } ; 

| pass en switchtype [delay2] pass_enable_switch_instance { , pass_enable_switch_instance } ; 

| pass switchtype pass_switch_instance { , pass_switch_instance } ; 

| pulldown [pulldown_strength] pull_gate_instance { , pull_gate_instance } ; 

| pullup [pullup strength] pull _gate_instance { , pull_gate_instance } ; 
cmos_switch_instance ::= [ name_of_gate_instance ] ( output terminal , input_terminal , 
ncontrolterminal , pcontrol_terminal ) 

enable_gate_instance ::= [ name_of_gate_instance ] ( output__terminal , input_terminal , enable_terminal ) 
mos_switch_instance [ name_of_gate_instance ] ( output_terminal , input_terminal , enable_terminal ) 
njnput _gate_instance [ name_of_gate_instance ] ( output_terminal , input Jerminal { , input_terminal 

}) 

n_output __gate_instance [ name_of _gate_instance ] ( outputjerminal { , output terminal } , 

input__terminal ) 

pass_switch_instance ::= [ name of gate instance ] ( inout terminal , inout_terminal ) 
pass_enable_switch_instance ::= [ name_of _gate_instance ] ( inout_terminal , inout terminal , 
enable_terminal ) 

pull_gate_instance ::= [ name_of_gate_instance ] ( output_terminal ) 
name_of_gate_instance gate_instance_identifier { unpacked_dimension } 

A.3.2 Primitive strengths 

pulldown__strength ::= 

( strengthO , strength 1 ) 

| ( strength 1 , strengthO ) 

| ( strengthO ) 
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pullup_strength ::= 

( strengthO , strength 1 ) 

| ( strength 1 , strengthO ) 

| ( strength 1 ) 

A.3.3 Primitive terminals 

enable Jerminal ::= expression 
inout_terminal ::= netjvalue 
input_terminal ::= expression 
ncontrol_terminal ::= expression 
output terminal ::= net lvalue 
pcontrol_terminal ::= expression 

A.3.4 Primitive gate and switch types 

cmos_switchtype cmos | rcmos 
enable_gatetype ::= btififO | bufifl | notifO | notifl 
mos_switchtype ::= nmos | pmos | rnmos | rpmos 
n_input_gatetype ::= and | nand | or | nor | xor | xnor 
n_output_gatetype ::= buf | not 

pass_en_switchtype tranifO | tranifl | rtranitl | rtranifO 
pass switchtype ::= tran | rtran 

A.4 Module, interface and generated instantiation 

A.4.1 Instantiation 

A.4.1.1 Module instantiation 

module instantiation ::= 

module identifier [ parameter value assignment ] module_instance { , modulejnstance } ; 
parameter_value_assignment ::= # ( list_of_parameter_assignments ) 
list_of_parameter_assignments ::= 

ordered_parameter_assignment { , ordered_parameter_assignment } 

| named_parameter_assignment { , named_parameter_assignment } 
ordered_parameter_assignment ::= param_expression 

named_parameter_assignment ::= . parameter_identifier ( [ param_expression ] ) 
modulejnstance ::= name_ofJnstance ( [ list_of_port_connections ] ) 
name_of instance ::= modulejnstance identifier { unpacked dimension } 

list_of_port_connections 1 8 ::= 

ordered_port_connection { , orderedj)ort_connection } 

| named_port_connection { , named__port_connection } 
ordered_port_connection ::= { attribute instance } [ expression ] 
named_port_connection ::= 

{ attributejnstance } . portjdentifier [ ( [ expression ] ) ] 

| { attributejnstance } .* 
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A.4.1.2 Interface instantiation 

interface_instantiation ::= 

interface_identifier [ parameter_value_assignment ] module_instance { , module Jnstance } ; 

A.4.1.3 Program instantiation 

program_instantiation 

programjdentifier [ parameter_value_assignment ] programjnstance { , programjnstance } ; 
program_instance ::= program_instance_identifier { unpacked_dimension } ( [ list_of_port_connections ] ) 

A.4.2 Generated instantiation 
A.4.2.1 Generated module instantiation 

generated_moduleinstantiation generate { generate_moduleJtem } endgenerate 
generatemoduleitem ::= 

generate_module_conditional_statement 
| generate_moduIe_case_statement 
| generate_moduleJoop_statement 
| f generatejriockjdentifier : ] generate module block 
| module_or_generateitem 
generate_module_conditional_statement : := 

if ( constant_expression ) generate_module_item [ else generate_moduleJtem ] 
generate_module_case_statement : := 

case ( constant_expression ) genvar_module_case_item { genvar_module_case_item }endcase 
genvar_module_case_item ::= 

constant_expression { , constant_expression } : generate_module_item 
| default [ : ] generate_moduleitem 
generate_moduleJoop_statement : := 

for ( genvardeclassignment ; constant_expression ; genvar_assignment ) 
generate_module_named_block 
genvar__assignment ::= 

genvar_identifier assignment_operator constant_expression 
| inc_or_dec_operator genvarjdentifier 
| genvar_identifier inc_or_dec_operator 
genvardeclassignment 

[ genvar ] genvarjdentifier = constantexpression 
generate_module_named_block ::= 

begin : generate_block identifier { generate_moduleJtem } end [ : generatejjlockjdentifier ] 

| generate_blockJdentifier : generate_module_b!ock 
generate_module_block ::= 

begin [ : generate_blockJdentifier ] { generate_module Jtem } end [ : generate__blockJdentifier] 

A.4.2.2 Generated interface instantiation 

generated JnterfaceJnstantiation ::= generate { generate JnterfaceJtem } endgenerate 
generate Jnterface Jtem ::= 

generateinterface_conditional_statement 
| generate interface_case_statement 
| generate interfaceJoop_statement 
| [ generatejdockjdentifier : ] generate interface_block 
| interface_orj>enerateJtem 
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generate Jnterface_conditional_statement : := 

if ( constant_expression ) generate_interface_item [ else generate interface Jtem ] 
generate_interface_case_statement : := 

case ( constant_expression ) genvar_interface_case_item { genvar_interface_case_item } endcase 
genvarjnterface_casejtem 

constant_expression { , constant_expression } : generate_interface_item 
| default [ : ] generate_interface_item 
generate JnterfaceJoop_statement : := 

for ( genvar_decl_assignment ; constant_expression ; genvarassignment ) 
generate_interface_named_block 
generate Jnterface_namedJ>lock : := 

begin : generateblockjdentifier { generate_interface_item } end [ : generateblockjdentifier ] 

| generate_block_identifier : generate_interface_block 
generate_interface_block 

begin [ : generate_block_identifier ] 

{ generate_interface_item } 
end [ : generatejdock identifier ] 

A.5 UDP declaration and instantiation 
A.5.1 UDP declaration 

udpnonansideclaration ::= 

{ attributejnstance } primitive udp_identifier ( udp_port_list ) ; 
udp_ansi_declaration ::= 

{ attribute_instance } primitive udpjdentifier ( udp_declaration_port_list ) ; 
udp_declaration ::= 

udp__nonansi_declaration udp_port_declaration { udp_port_declaration } 
udp_body 

endprimitive [ : udp_identifier ] 

| udp_ansi_declaration udpbody endprimitive [ : udpjdentifier ] 

| extern udp_nonansi_declaration 

| extern udp_ansi_declaration 

| { attributejnstance } primitive udpjdentifier ( .* ) ; 

{ udp_port_declaration } udp_body endprimitive [ : udpjdentifier ] 

A.5.2 UDP ports 

udp_portJist ::= output_portJdentifier , input_portJdentifier { . input_port identifier } 
udp_declaration_j)ortJist ::= udp_output_declaration , udp_input_declaration { , udpJnput_declaration } 
udp_port_declaration ::= 

udp_output_declaration ; 

| udp_input_declaration ; 

| udp_reg_declaration ; 
udp_output_declaration ::= 

{ attributejnstance } output port identifier 
| { attributejnstance } output reg portjdentifier [ = constant_expression ] 
udpjnput declaration { attributejnstance } input Iist_of_udp_portJdentifiers 
udp_reg_declaration ::= { attributejnstance } reg variable Jdentifier 
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A.5.3 UDP body 

udp__body combinationalbody | sequential_body 

combinational__body ::= table combinational__entry { combinational_entry } endtable 
combinational_entry level_input_list : output_symbol ; 

sequential_body [ udp initial statement ] table sequential__entry { sequentialentry } endtable 

udp_initial_statement ::= initial output _portJdentifier = init_val ; 

initial V bO | Tbl 1 1 ’bx 1 1 ’bX | 1 'BO 1 1’ Bl 1 1 ’Bx | 1’BX 1 1 1 0 

sequential entry ::= seq_input_list : current_state : next_state ; 

seq_input_list level_input_list | edge_input_list 

level JnputJist ::= level_symbol { levelsymbol } 

edge_input_list ::= { level__symbol } edge_indicator { level_symbol } 

edgejndicator ::= ( level_symbol level_symbol ) | edge_symbol 

current__state level symbol 

next_state ::= output_symbol | - 

output_symbol ::= 0 1 1 | x | X 

level jsymbol ::= 0 1 1 | x | X | ? | b | B 

edge_symbol ::=r|R|f|F|p|P|n|N|* 

A.5.4 UDP instantiation 

udpjnstantiation ::= udp identifier [ drive_strength ] [ delay2 ] udp_instance { , udpjnstance } ; 
udp instance ::= [ name_of_udp_instance ] ( output terminal , input_terminal { , input_terminal } ) 
name_of_udp_instance ::= udp_instance_identifier { unpacked_dimension } 

A.6 Behavioral statements 

A.6.1 Continuous assignment and net alias statements 

continuous_assign 

assign [ drive strength ] [ delay3 ] list_of_net_assignments ; 

| assign [ delay_control ] list_of_variable__assignments ; 
list_of_net_assignments net_assignment { , net_assignment } 
list_of_variable_assignments variable_assignment { , variable_assignment } 
net alias alias netjvalue = netjvalue { = netjvalue } ; 
net_assignment net_lvalue = expression 

A.6.2 Procedural blocks and assignments 

initial_construct ::= initial statement_or_nuIl 
always__construct ::= always statement 
combinationalconstruct ::= always_comb statement 
latch_construct always latch statement 
ff_construct ::= alwaysff statement 
fmal_construct ::= final function_statement 
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blockingassignment ::= 

variablejvalue = delay_or_event_control expression 
| hierarchical_variable_identifier = new j constantexpression ] [ ( variable Jdentifier ) ] 
| class_variable_identifier = new [ ( list_of_arguments ) ] 

| classvariableidentifier . randomize [ ( ) ] with constraint_block ; 

| operator_assignment 

operatorassignment ::= variablejvalue assignment_operator expression 
assignment_operator ::= 

= i +=i-=i*= i /=i%=i&= 1 1=1 a= i « = i >>= i <«= i »>= 

nonblocking assignment ::= variablejvalue <= [ delay_or_event_control ] expression 
procedural_continuous_assignments : := 
assign variable assignment 
| deassign variablejvalue 
| force variable_assignment 
| force net_assignment 
| release variablejvalue 
| release net J value 

variable_assignment variablejvalue = expression 

A.6.3 Parallel and sequential blocks 

action J>lock ::= 

statement_or_null 

| [ statement ] else statement_or_null 
seq_block ::= 

begin [ : block Jdentifier ] { blockJtem_declaration } { statement_or_null } 
end [ : blockjdentifier ] 
parjdock ::= 

fork [ : blockjdentifier ] { block item_declaration } { statement_or_null } 
join_keyword [ : blockjdentifier ] 
join_keyword ::= join | join_any | join none 

A.6.4 Statements 

statement_or_null ::= 
statement 

| { attributejnstance } ; 

statement ::= [ block identifier : ] { attributejnstance } statement item 
statement Jtem ::= 

blocking_assignment ; 

| nonblocking_assignment ; 

| procedural_continuous_assignments ; 

| case_statement 
| conditional_statement 
| inc_or_dec_expression ; 

| function_call ; 

| disable statement 
| event Jrigger 
| loop_statement 
| jump_statement 
| par_block 
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| proceduraltimingcontrolstatement 
| seq_block 
| system_task_enable 
| taskenable 
| wait_statement 
| procedural_assertion_item 
| clocking_drive 
| void ' ( function_call ) 

| randsequence 
| scope_randomize 
| randcase_statement 

| expect ( property_spec ) [ action_block ] 

| expect ( property_instance ) [ action_block ] 
function_statement ::= statement 
fiinction_statement_or_null ::= 
function_statement 
| { attribute instance } ; 

scope_randomize randomize ( [ variable_identifierjist ] ) [ with { constraint_block } ] 

variable_identifier_list ::= variable_identifier { , variable identifier } 

A.6.5 Timing control statements 

procedural_timing_control_statement : := 

proceduraltimingcontrol statement_or_null 
delay or event control 
delay_control 
| event_control 

| repeat ( expression ) event_control 
delaycontrol ::= 

# delayvalue 

| # ( mintypmax expression ) 
event_control ::= 

@ hierarchical_event_identifier 
| @ ( event_expression ) 

i 

i @ (*) 

| @ sequence_instance 
event_expression ::= 

[ edge identifier ] expression [ iff expression ] 

| sequence instance [ iff expression ] 

| event_expression or event_expression 
| event_expression , event_expression 
procedural Jimingcontrol ::= 
delaycontrol 
| event_control 
jump_statement 

return [ expression ] ; 

| break ; 

| continue ; 
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wait_statement ::= 

wait ( expression ) statement_or_null 
| wait fork ; 

| wait_order ( hierarchical_identifier [ , hierarchical_identifier ] ) action_block 
event Jrigger ::= 

-> hierarchicaleventidentifier ; 

|-» [ delay_or_event_control ] hierarchicaleventidentifier ; 
disable_statement ::= 

disable hierarchicaljaskidentifier ; 

| disable hierarchical block identifier ; 

| disable fork ; 

A.6.6 Conditional statements 

conditional_statement 

if ( expression ) statement_or_null [ else statement__or_null ] 

| unique_priorityif_statement 
unique_priorityif_statement ::= 

[ unique_priority ] if ( expression ) statement_or_null 
{ else if ( expression ) statement_or_null } 

[ else statement_or_nulI ] 
unique_priority unique | priority 

A.6.7 Case statements 

case_statement 

[ unique_priority ] case ( expression ) casejtem { casejtem } endcase 
| [ unique_priority ] casez ( expression ) casejtem { case item } endcase 
| [ unique_priority ] casex ( expression ) case item { case item } endcase 
casejtem ::= 

expression { . expression } : statement__or_null 
| default [ : ] statementornull 
randcase_statement ::= 

randcase randcasejtem { randcasejtem } endcase 
randcasejtem expression : statement or null 

A.6.8 Looping statements 

loop_statement ::= 

forever statement_or_null 
| repeat ( expression ) statement__or_null 
| while ( expression ) statement jjrjiull 
| for ( forjnitialization ; expression ; for_step ) 
statement_or_null 

| do statement_or_null while ( expression ) ; 

| foreach ( array Jdentifier [ loop_variables ] ) statement 
forjnitialization ::= 

Iist_ o f_ var iable_assignments 

| data type list_ofvariable__assignments { , data_type list_ofvariable_assignments } 
for step ::= for_step_assignment { , for_step_assignment } 
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for_step_assignment ::= 

operator_assignment 
| inc_or_dec_expression 

loop_variables [ indexidentifier ] { . [ index_identifier ] } 

A.6.9 Task enable statements 

system__task_enable system_task_identifier [ ( [ expression ] { , [ expression ] } ) ] ; 
task_enable ::= hierarchical_task_identifier [ ( list_of_arguments ) ] ; 

A.6.10 Assertion statements 

procedural__assertion_item 

assert jaroperty^statement 
| coverjDroperty statement 
| immediate assert statement 
immediate_assert_statement ::= 

assert ( expression ) action_block 

A.6.11 Clocking domain 

clocking_decl ::= [ default ] clocking [ clockingidentifier ] clocking event ; 

{ clockingjtem } 
endclocking 
clocking_event ::= 

(a} identifier 

| @ ( event_expression ) 
clocking_item := 

default default_skew ; 

| clocking direction list of clocking decl assign ; 

| { attribute_instance } concurrent_assertion_item_declaration 
default skew 

input clockingskew 
| output clocking_skew 
| input clocking skew output clocking_skew 
clocking_direction ::= 

input [ clockingskew ] 

| output [ clocking_skew ] 

| input [ clockingskew ] output [ clocking_skew ] 

| inout 

list_of_ c l oc king_decl_assign ::= clocking_decl_assign { , clocking_decl_assign } 
clocking_decI_assign ::= signaMdentifier [ = hierarchical_identifier ] 
cIocking_skew 

edge_identifier [ delay_control ] 

| delay_control 
clocking_drive ::= 

clockvarexpression <= [ cycle_delay ] expression 
| cycle_delay clockvar expression <= expression 
cycle_delay ::= ## expression 
clockvar ::= clockingidentifier . identifier 
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clockvarexpression 
clockvar range 

| clockvar | range_expression | 

A.6.12 Randsequence 

randsequence ::= randsequence f [ production_ identifier ] ) 
production { production } 
endsequence 

production [ function_dataJype ] production_name [ ( tf_port_list ) ] : rs_rule { | rs_rule } ; 
rs_rule ::= rs_production_list [ := expression [ rs_code_block ] ] 
reproduction list ::= 

rs_prod { rs_prod } 

| l and join [ ( expression ) ] productionjtem production Jtem { productionjtem } 
rs_code_block ::= { { data_declaration } { statement_or_null } } 
rs_prod ::= 

production_item 
| rs_code_block 
I rs_if_else 
| rs_repeat 
| rs_case 

production item ::= production_identifier [ ( list_of_arguments ) ] 
rs if else ::= if ( expression ) production_item [ else production_item ] 
rs_repeat ::= repeat ( expression ) productionjtem 
rs_case case ( expression ) rs_case_item { rs__casejtem } endease 
rs_case_item ::= 

expression { , expression } : productionjtem 
| default [ : ] productionjtem 

A.7 Specify section 

A.7.1 Specify block declaration 

specify J>lock ::= specify { specify Jtem } endspecifv 
specify Jtem ::= 

specparam_declaration 
| pulsestyle_declaration 
| showcancelled_declaration 
| path declaration 
| system timing_check 
pulsestyle_declaration ::= 

pulsestyIe_onevent 1 i st_o f_path_outputs ; 

| pulsestyle_ondetect list_of_path_outputs ; 
showcancelled_declaration 

shoHcancelled list_of_path_outputs ; 

| noshowcancelled list_of_path_outputs ; 



From SystemVerilog 3.1a draft 2 LRM. Copyright 2003 Accellera. All rights reserved. 




344 



SystemVerilog for Design 



A.7.2 Specify path declarations 

path_declaration 

simple_path_declaration ; 

| edge_sensitive_path_declaration ; 

| state_dependent_path_declaration ; 
simple_path_declaration 

parallel_path_description = path_delay_value 
| fulljpath_description = path_delay_value 
parallel_path_description ::= 

( specify JnputJerminal_descriptor [ polarity_operator ] => specify_output_terminal_descriptor ) 
full_path_description ::= 

( list_of_path_inputs [ polarity_operator ] *> list_of_path_outputs ) 
list_of_path_inputs ::= 

specify_input_terminal_descriptor { , specify JnputJerminal_descriptor } 
list_of_path_outputs ::= 

specify_output_terminal_descriptor { , specify j>utputJerminal_descriptor } 

A.7.3 Specify block terminals 

specify Jnput_terminal_descriptor : := 

inputjdentifier [ | constant_range__expression | ] 
specify_output_terminal_descriptor : := 

output ^identifier [ | constant _range_expression ] ] 
inputjdentifier ::= input jx>rt_identifier | inout_port_identifier | interface_identifier.port_identifier 
output identifier ::= output_port_identi fier | inout_port_identifier | interface_identifier.port_identifier 

A.7.4 Specify path delays 

path delay value 

list_of_path_delay_expressions 
| ( list_of_path_delay_expressions ) 
list__of_path_delay_expressions : 
t_path_delay_expression 

| trise_path_de!ay_expression , tfaIl_path_deIay_expression 

| trise__path_delay_expression , tfall_path_delay_expression , tz_path_delay_expression 
| tO l_path_delay_expression , 1 1 0_path_delay_expression , tOz_path_delay_expression , 
tz l_path_delay_expression , 1 1 z_path_delay_expression , tzO_path_delay_expression 
I tO 1 _path_delay_expression , 1 1 0_path_delay_expression , tOz_path_delay_expression , 
tzl_path_delay_expression , 1 1 z_path_delay_expression , tzO_path_delay_expression , 
tOx_path_delay_expression , tx l_path_delay_expression , 1 1 x_path_delay_expression , 
txO_path_delay_expression , txz_path_delay_expression . tzx_path_delay_expression 
t_path_delay_expression path_delay_expression 
trise_path_delay_expression ::= path_delay_expression 
tfall_path_delay_expression path__delay_expression 
t z _path_delay_expression path_delay_expression 
tO 1 _path_delay__expression ::= path_delay_expression 
1 1 0_path_delay_expression ::= path_delay_expression 
tOz__path_delay_expression ::= path_delay_expression 
tz 1 _path_delay_expression path_delay_expression 

1 1 z_path_delay_expression path_delay_expression 
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tzO_path_delay__expression ::= path_delay_expression 
tOx_path_delay_expression ::= path_delay_expression 
txl_path_delay_expression path__delay_expression 
tlx_path_delay_expression ::= path_delay_expression 
txO_path_delay_expression ::= path delay expression 
txz_path_delay_expression ::= path_delay_expression 
tzx_path_delay_expression ::= path_delay_expression 
path_delay_expression constant_mintypmax_expression 
edge_sensitive_path_declaration : := 

parallel_edge_sensitive_path_description = path_delay_value 
| full_edge_sensitive_path_description = path_delay_value 
parallel_edge_sensitive jpath_description : := 

( [ edgejdentifier ] specify JnputJerminal_descriptor => 

( specify_output_terminal_descriptor [ polarity_operator ] : data_source_expression ) ) 
full_edge_sensitive_path_description : := 

( [ edgejdentifier ] list_of_pathJnputs *> 

( list_of_path_outputs [ polarity operator ] : data_source_expression ) ) 
data_source_expression ::= expression 
edgejdentifier ::= posed ge | negedge 
state_dependent_path_declaration : := 

if ( module_path_expression ) simple_path_declaration 
| if ( module_path_expression ) edge_sensitive_path_declaration 
| ifnone simp!e_path_declaration 
polarity_operator ::= + 1 - 

A.7.5 System timing checks 

A.7.5.1 System timing check commands 

system timing_check ::= 

$setupjiming_check 
| $holdJiming_check 
| $setupholdJiming_check 
| $recoveryJiming_check 
| $removalJiming_check 
| $recremjiming_check 
| $skew timing_check 
| $timeskew timing_check 
| $f\illskewjiming_check 
| Speriodjiming check 
| Swidthjiming_check 
| $nochangeJiming_check 
$setupjiming_check 

Ssetup ( data__event . reference_event , timing check limit [ , [ notify_reg ] ] ) ; 
$holdJiming_check ::= 

$hold ( reference__event , data_event , timing check limit [ , [ notify_reg ] ] ) : 
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$setuphold_timing_check 

$setuphoId ( referenceevent , data_event , timingchecklimit , timingchecklimit 
[ , [ notify_reg ] [ , [ stamptime_condition ] [ , [ checktime_condition ] 

[ , [ delayed ^reference ] [ , [ delayed_data ]]]]]]); 

$recovery_timing_check 

^recovery ( reference_event , data_event , timing_check_limit [ , [ notify_reg ] ] ) ; 
$removal_timing_check ::= 

Sremoval ( reference_event , data_event , timing_check_limit [ , [ notify_reg ] ] ) ; 
$recrem_timing_check ::= 

Srecreni ( reference_event , data_event , timing_check_limit , timing__checkjimit 
[ , [ notify_reg ] [ , [ stamptime_condition ] [ , [ checktime_condition ] 

[ , [ delayed_reference ] [ , [ delayed_data ]]]]]]); 

$skew_timing_check 

$skew ( reference_event , data_event , timing check limit [ , [ notify reg ] ] ) ; 
$timeskew_timing_check ::= 

$timcskcw ( reference_event , data_event , timing_check_limit 

[ , [ notify_reg ] [ , [ event_based_flag ] [ , [ remain_active_flag ]]]]); 
$fullskew_timing_check ::= 

$fullskew ( reference_event , data_event , timing_check_limit , timing_check_limit 
[ , [ notify reg ] [ , [ event_based_flag ] [ , [ remain_active_flag ]]]])? 
$period_timing_check ::= 

Speriod ( controlled_reference_event , timing_check_limit [ , [ notify reg ] ] ) ; 
Swidthtimingcheck ::= 

$width ( contro 1 led re ference e vent , timing_checkjimit , threshold [ , [ notify_reg ] ] ) ; 
$nochange_timing_check ::= 

$nochauge ( reference_event , data_event , start__edge__offset , 
end_edge_offset [ , [ notify_reg ] ] ) ; 

A.7.5.2 System timing check command arguments 

checktime_condition ::= mintypmax expression 
controlled_reference__event controlled_timing_check_event 
data__event ::= timing_check_event 
delayed_data ::= 

terminalidentifier 

| terminal_identifier [ constant jmntypmax_expression ] 
delayed_reference ::= 

terminalidentifier 

| terminaljdentifier [ constant_mintypmax_expression | 
end_edge_offset mintypmax_expression 
event_based_flag ::= constant_expression 
notify_reg ::= variablejdentifier 
referenceevent ::= timing_check__event 
remain_active_flag ::= constant_mintypmax_expression 
stamptime_condition ::= mintypmax_expression 
start_edge_offset ::= mintypmaxexpression 
threshold ::=constant_expression 
timingchecklimit ::= expression 
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A.7.5.3 System timing check event definitions 

timingcheckevent ::= 

[timing_check_event_control] specify_terminal_descriptor [ &&& timingcheckcondition ] 
controlled_timing_check_event : := 

timing_check_event_control specify_terminal_descriptor [ &&& timingcheckcondition ] 
timing_check_event_control ::= 
posedge 
| negedge 

| edge_control_specifier 
specify_terminal_descriptor ::= 

speci fy_input_terminal_descriptor 
| specify_output_terminal_descriptor 
edge_control_specifier ::= edge f edge_descriptor { , edge_descriptor } | 
edgedescriptor 1 ::=01 | 1 0 1 z_or_x zero_or_one | zero_or_one z_or_x 
zero_or_one ::= 0 1 1 
z_or_x ::= x | X | z | Z 
timing_check_condition ::= 

scalar_timing_check_condition 
| ( scalartimingcheckcondition ) 
scalar_timing_check_condition ::= 
expression 
| - expression 

| expression == sca!ar_constant 
| expression = scalar_constant 
| expression != scalar_constant 
| expression != scalarconstant 

scalar constant ::= TbO | Tbl | I’BO | VB\ | ’bO | ’bl | ’BO | ? B1 1 1 | 0 

A.8 Expressions 
A.8.1 Concatenations 

concatenation ::= 

{ expression { , expression } } 

| { struct member label : expression { , struct_member_label : expression } } 

| { array_member_label : expression { , array_member_label : expression } \ 
constant_concatenation 

{ constant_expression { . constant_expression } } 

| { struct_member_label : constant__expression { , struct_memberjabel : constant expression } ) 
| ( array_member_label : constant_expression { , array_member_label : constantexpression } } 
struct member label ::= 
default 

| type_identifier 
| variable_identifier 
array_member_label ::= 
default 

| type_identifier 
| constant_expression 

constant_multipIe_concatenation ::= { constant_expression constant concatenation } 
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module j)ath_concatenation ::= { module jpath_expression { , module_path_expression } } 
module_path_multiple_concatenation ::= { constant_expression module__path_concatenation } 
multiple_concatenation ::= { expression concatenation } 20 
streaming_expression { stream_operator [ slice__size ] stream_concatenation } 
stream_operator » | « 
slice_size ::= type_identifier | constant_expression 
stream_concatenation ::= { stream_expression { , stream_expression } } 
stream expression ::= 
expression 

| array Jdentifier [ with f array_range_expression ) ] 
array_range_expression ::= 
expression 

| expression : expression 
| expression +: expression 
| expression expression 

A.8.2 Function calls 

constant_function_call ::= function Jdentifier { attributejnstance } 

[ ( list_ofconstant_arguments ) ] 

function_call ::= hierarchical Junctionidentifier { attributejnstance } [ ( list_of_arguments ) ] 
list_of_arguments ::= 

[ expression ] { , [ expression ] } { , . identifier ( [ expression ] ) } 

| . identifier ( [ expression ] ) { , . identifier ( [ expression ] ) } 
list_of_constant_arguments 

[ constant expression ] { , [ constant_expression ] } 

| . identifier ( [ constant_expression ] ) { , . identifier ( [ constant_expression ] ) } 
system_function_call ::= system_function__identifier [ ( expression { , expression } ) ] 
array jnethod_call ::= 

array_identifier . method_identifier [ ( [ iterator_identifier ] ) ] [ with ( expression ) ] 

A.8.3 Expressions 

base__expression expression 
inc_or_dec_expression 

inc_or_dec_operator { attributejnstance } variablejvalue 
| variablejvalue { attributejnstance } inc_or_dec_operator 
conditional_expression expression ? { attributejnstance } expression : expression 
constant J>ase_expression constant_expression 

constant_expression ::= 
constant jprimary 

| unary_operator { attributejnstance } constant_primary 
| constant expression binary_operator { attributejnstance } constant_expression 
| constant_expression ? { attributejnstance } constantexpression : constant_expression 
| stringjiteral 

constant_mintypmax_expression ::= 
constant__expression 

| constantexpression : constantexpression : constant expression 
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constant_param_expression ::= 

constant_mintypmax_expression | datajype 
param_expression ::= mintypmax_expression | data_type 
constant_range_expression ::= 
constant_expression 

| msb_constant_expression : lsb_constant_expression 
| constant_base_expression +: width_constant_expression 
| constant_base_expression width_constant_expression 
dimension_constant_expression ::= constant_expression 
expression ::= 
primary 

| unary operator { attributejnstance } primary 
| inc_or_dec_expression 
| ( operatorassignment ) 

| expression binary operator { attribute_instance } expression 
| conditional_expression 
| stringjiteral 
| inside_expression 

| expression . method_identifier { attributejnstance } [ ( list_of_arguments ) ] 
inside_expression ::= expression inside { open_rangeJist } 
range Jist_or_array 

variablejdentifier 
| { value_range { , value_range } } 
value_range ::= 
expression 

| | expression : expression | 
lsb__constant_expression ::= constant_expression 
mintypmax_expression 
expression 

| expression : expression : expression 

module_path_conditional_expression ::= module_path_expression ? { attributejnstance } 
module_path_expression : module_path_expression 
module_path_expression ::= 
module_j)ath_primary 

| unary_module_path_operator { attributejnstance } module_path_primary 
| module_path_expression binary_module__path_operator { attribute_instance } 
module__path_expression 
| module_path_conditional_expression 
module_path_mintypmax_expression : := 
moduIej)ath_expression 

| module_path_expression : modulej3ath_expression : module_path_expression 
msb_constant_expression ::= constant_expression 
range_expression ::= 
expression 

| msb_constant_expression : lsb_constant_expression 
| base_expression +: width_constant_expression 
| base_expression width_constant_expression 
width_constant_expression ::= constant_expression 
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A.8.4 Primaries 

constant_primary ::= 

constant_concatenation 
| constant_ftinction_call 
| ( constant_mintypmax_expression ) 

| constant multiple_concatenation 
| genvar_identifier 
| number 
| enum_identifier 
| parameterjdentifler 
| specparamjdentifier 
| casting_type ’ ( constant_expression ) 

| castingtype ’ constant concatenation 
| casting_type ' constant_multiple_concatenation 
| timejiteral 

| ’0 1 ’1 | ’z | ’Z | | ’X 11 

module_path_primary : := 
number 
| identifier 

| module_path_concatenation 
| module_path_multiple_concatenation 
| function_call 
| system function call 
| ( module_path_mintypmax_expression ) 
primary ::= 
number 

| implicit class handle hierarchical_identifier { ( expression I } [ [ range_expression | ] 
| concatenation 
| multiple_concatenation 
| function_call 
| system_fiinction_call 
| array method call 

| class scope :: identifier { | expression j } [ | range__expression | ] 

| ( mintypmax_expression ) 

| casting type ' ( expression ) 

| castingtype • concatenation 
| casting_type ■ multiple concatenation 
| streaming__expression 
| time_literal 

| ’0 1 ’1 | ’z | ’Z | ’x | ’X 11 
| null 

time_l iteral 5 

unsigned_number time_unit 
| fixedj3oint_number time_unit 
time_unit ::= s | ms | us | ns | ps | fs | step 
implicit_class_h an( il e7 : - = [ this. ] | [ super. ] 
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A.8.5 Expression left-side values 

netjvalue ::= 

hierarchical_net_identifier { j constant_expression 1 } [ | constant_range_expression | ] 
| { net_lvalue { . netjvalue } } 
variable lvalue ::= 

hierarchical_variablejdentifier { [ expression ] } [ | range_expression | ] 

| { variablejvalue { , variablejvalue } } 

A.8.6 Operators 

unaryoperator ::= 
binary_operator ::= 

+ 1-1 * l/l % I = |!-| = |!=-|«?«| !?=|&& 1 1||*‘ 

I < I <= I > I >= I & 1 1 1 A I A ~ I ~ A I » I « I »> I «< 

inc_or_dec_operator ::= ++ 1 — 
unaty_module_path_operator ::= 

!H&i~&m~iri~ A i A ~ 

binary_module_path_operator ::= 

==i!=i&&ini&im^i^ 

A.8.7 Numbers 

number ::= 

decimal_number 
| octal_number 
| binary_number 
| hex_number 
| real_number 
decimal_number ::= 

unsigned_number 

| [ size ] decimal J>ase unsigned_number 
| [ size ] decimal J)ase x_digit { _ } 

| [ size ] decimal_base z_digit { _ } 
binary_number ::= [ size ] binary Jjase binary_value 
octal_number ::= [ size ] octal_base octal_value 
hex_number ::= [ size ] hex_base hex_value 
sign ::= + 1 - 

size ::= non_zero_unsigned_number 

non_zero_unsigned_number I ::= non_zero_decimal_digit { _ | decimal digit} 

realnumber 1 ::= 

fixed__point_number 

| unsigned_number [ . unsigned_number ] exp [ sign ] unsigned_number 
fixedjjointnumber 1 ::= unsigned_number . unsigned_number 
exp e | E 

unsigned^umber 1 ::= decimal_digit { _ | decimal_digit } 
binary value 1 ::= binary_digit { _ | binary_digit } 
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decimaljjase 1 ’[s|S]d | , [s|S]I> 

binary Jrase 1 ::= ■ [s|S]b | ’[s|S]B 

octaljjase 1 ::= ’[s|S]o | '[s|S]0 

hex_base l ’[s|S]h | ’[s|S]H 

non_zero_decimal_digit 1 | 2 | 3 | 4 | 5 1 6 1 7 1 8 1 9 

decimaldigit ::=0|1|2|3|4|5|6|7|8|9 

binary_digit ::= x_digit | z digit | 0 1 1 

octal_digit ::= x__digit | z_digit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 

hex_digit x_digit | z_digit | 0 1 1 | 2 | 3 | 4 1 5 | 6 | 7 | 8 | 9 | a | b | c | d | e | f | A | B | C | D | E | F 
x__digit ::= x | X 
z_digit ::= z | Z | ? 

A.8.8 Strings 

string Jiteral ::= ” { Any_ASCII_Characters } ” 

A.9 General 
A.9.1 Attributes 

attribute Jnstance ::= (* attr_spec { , attr spec } *) 
attr_spec ::= attr name [ = constant_expression ] 
attr_name ::= identifier 

A.9.2 Comments 

comment ::= 

one_line_comment 
| block_comment 

one_line_comment ::= // comment_text \n 
block_comment ::= /* comment_text *1 
comment__text { Any_ASCII_character } 

A.9.3 Identifiers 

array__identifier ::= identifier 
block_identifier ::= identifier 
binidentifier identifier 
c identifier 2 [ a-zA-Z_ ] { [ a-zA-Z0-9_ ] } 
celHdentifier ::= identifier 
class_identifier ::= identifier 
class_variable_identifier ::= variable identifier 
clocking_identifier identifier 
config_identifier ::= identifier 
constrainMdentifier identifier 
covergroupjdentifier ::= identifier 
covergroup_variable_identif!er variable_identifler 
cover_point_identifier identifier 
enumidentifier identifier 

escaped__identifier ::= \ {any_ASCII_character_except_white_space} white_space 
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enum identifier ::= identifier 

escaped_identifier ::= \ {any_ASCII_character_except_white_space} white_space 

formal Jdentifier ::= identifier 

fimction_identifier identifier 

gate instance Jdentifier ::= identifier 

generate J)lock identifier identifier 

genvar Jdentifier ::= identifier 

hierarchicalblockjdentifier ::= hierarchical_identifier 
hierarchical_event_identifier hierarchical_identifier 
hierarchical_function Jdentifier ::= hierarchical_identifier 
hierarchical_identifier ::= { identifier { [ constant_expression ] } . } identifier 
hierarchical_parameter_identifier hierarchical Jdentifier 

hierarchical_net_identifier hierarchical_identifier 
hierarchical_variable Jdentifier ::= hierarchical_identifier 
hierarchical_task_identifier ::= hierarchical_identifier 
identifier ::= 

simple_identifier 
| escapedjdentifier 
index identifier identifier 
interface Jdentifier identifier 

interface_instance_identifier ::= identifier 
inout_port Jdentifier identifier 

input j)ort_identifier ::= identifier 
instance_identifier ::= identifier 
library_identifier ::= identifier 
memberidentifier identifier 
method_identifier ::= identifier 
modportidentifier identifier 
moduleidentifier ::= identifier 
module Jnstance_identifier ::= identifier 
netidentifier ::= identifier 
output jjort Jdentifier ::= identifier 
parameter identifier identifier 
port Jdentifier ::= identifier 
program Jdentifier ::= identifier 
program ^instance Jdentifier ::= identifier 
property Jdentifier ::= identifier 
sequence Jdentifier identifier 

signal Jdentifier ::= identifier 
simple identifier 2 ::= [ a-zA-Z_ ] { [ a-zA-Z0-9_$ ] } 
specparam Jdentifier ::= identifier 

systemjunctionjdentifier 3 $[ a-z A-Z0-9 S ] { [ a-zA-Z0-9_$ ] } 
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topmodule_identi fier ::= identifier 
typejdentifier ::= identifier 
udp_identifier ::= identifier 
udpjnstancejdentifier identifier 
variable_identifier ::= identifier 

A.9.4 White space 

white_space space | tab | newline | eof 4 

NOTES 

1) Embedded spaces are illegal. 

2) A simple ^identifier, c ^identifier, and arrayedreference shall start with an alpha or underscore ( 
_ ) character, shall have at least one character, and shall not have any spaces. 

3) The $ character in a system_fimction_identifier or system_task_identifier shall not be followed 
by white__space. A system_function_identifier or system_task_identifier shall not be escaped. 

4) End of file. 

5) The unsigned number or fixed point number in timejiteral shall not be followed by a 
white_space. 

6) The signed and unsigned keywords shall not be used within a function data type. Void 
functions, non integer type functions, unpacked structure or union functions, and functions with 
a typedef type cannot have a signing declaration. 

7) implicit class handle shall only appear within the scope of a class_declaration or 
extem_method_declaration. 

8) In any one declaration, only one of protected or local is allowed, only one of rand or randc is 
allowed, and static and/or virtual can appear only once. 

9) dpi_function_proto return types are restricted to small values, as per 27.4.5. 

10) Formals of dpi_function_proto cannot use pass by reference mode and class types cannot be 
passed at all; for the complete set of restrictions see 27.4.6. 

1 1) The apostrophe ( ' ) in constant jjrimary or primary shall not be followed by white_space. 

12) unsized_dimension is permitted only in declarations of import DPI functions, see 
dpi_function_proto. 

13) More than one unsized dimension is permitted only in declarations of import DPI functions, see 
dpi__function_proto. 

14) When a packed dimension is used with the struct or union keyword, the packed keyword 
shall also be used. 

15) A charge strength shall only be used with the trireg keyword. When the vectored or 
scalared keyword is used, there shall be at least one packed dimension. 

16) In a data_declaration that is not within the procedural context, it shall be illegal to use the 
automatic keyword. 
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15) A charge strength shall only be used with the trireg keyword. When the vectored or 
sc alar ed keyword is used, there shall be at least one packed dimension. 

16) In a data declaration that is not within the procedural context, it shall be illegal to use the 
automatic keyword. 

17) It shall be legal to omit the covergroup_variable_identifier from a covergroup instantiation only 
if this implicit instantiation is within a class that has no other instantiation of the covergroup. 

18) The .* token shall appear at most once in a list of port connections. 

19) A timeunits_declaration shall be legal as a non_port_module_item, non_port_interface_item, 
non_port__program_item, package_item or class item only if it repeats and matches a previous 
timeunits_declaration within the same time scope. 

20) In a multiple_concatenation, it shall be illegal for the multiplier not to be a constant__expression 
unless the type of the concatenation is string. 



From SystemVerilog 3.1a draft 2 LRM. Copyright 2003 Accellera. All rights reserved. 




Appendix B 

A History of SUPERLOG, The 
Beginning of System Verilog 



Simon Davidmann, one of the co-authors of this book, has been 
involved with the development of Hardware Description Languages 
since 1978. He has provided this brief history of the primary devel- 
opments that have led from rudimentary gate-level modeling in the 
1970s to the advanced SystemVerilog Hardware Design and Verifi- 
cation Language of 2003. His perspective of the development pro- 
cess of HDLs and the industry leaders that have brought about this 
evolution makes an interesting appendix to this book on using Sys- 
temVerilog for design. 
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B.1 Early days 



The current Hardware Description Languages (HDLs) as we know 
them have roots in the latter part of the 20th century. The first HDL 
that included both register transfer and timing constructs was the 
HILO [1] language, developed in the late 1970s in the UK by a 
team at Brunei University led by Peter Flake, which included Phil 
Moorby and Simon Davidmann (see Photo 1, below). The lan- 
guage, associated simulators, and test generator were funded in part 
by the UK’s Ministry of Defence and were targeted to produce and 
validate tests for PCBs and ICs. The development team at Brunei 
was spun out in 1983 into the UK’s Cirrus Computers Ltd. and 
thence in 1984 into GenRad, Inc. in the USA for commercializa- 
tion. 




Photo 1 : HILO-2 team circa 1981. (left to right) Simon Davidmann, Peter Flake, 
Phil Moorby, Gerry Musgrave, Bob Harris, Richard Wilson 
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In the early 1980s, the gate array based ASIC market started its 
growth to prominence. Though it had some success there, GenRad 
did not focus HILO development on ASIC design. Gateway Design 
Automation was founded in Massachusetts by Prabhu Goel specifi- 
cally to build ASIC verification tools. Prabhu Goel was the first 
user of HILO in the U.S. Phil Moorby joined Gateway, moved to 
the U.S., and conceived the Verilog HDL and Verilog-XL simula- 
tor. He based this initial version of Verilog (Verilog-86) on the 
HILO-2 gate level language and mechanisms, improving the bidi- 
rectional capabilities, and dramatically changed the higher level 
constructs (borrowing from C, Pascal and Occam) while improving 
the timing capabilities, and making them a fundamental part of the 
behavioral language. Verilog-XL was a significant commercial suc- 
cess, partly due to the inclusion of gate level, structural, and behav- 
ioral constructs all in one language. 

During the late 1980s, designers were predominantly using sche- 
matic capture packages to edit their structural designs, and gate 
level libraries supplied by ASIC vendors for their implementations. 
These vendors were very concerned about timing accuracy for 
design ‘sign off, and so Gateway added the ‘specify block’ and 
PLI delay calculators. The certification of Verilog-XL by all the 
ASIC vendors, driven by Martin Harding’s ASIC Business Group 
within Gateway, was one of the key reasons why Verilog was so 
successful. 

In the mid 1980s, Synopsys started to work with Verilog and ASIC 
vendors to produce its logic optimization and re-targeting tools. 
The piece that was missing was the Verilog Register Transfer Level 
(RTL) synthesis technology, which Synopsys released in 1988/89. 

By the early part of the 1990s, the design flow had changed from 
the 1980s methodology of schematics to Verilog RTL design and 
verification, Verilog RTL synthesis and functional simulation, and 
Verilog gate level timing simulation ‘sign off. As this move to an 
RTL methodology based on Verilog was taking place, Cadence 
Design Systems acquired Gateway, and thus took control of the 
(then) proprietary Verilog language. Most of the other EDA ven- 
dors did not have access to Verilog tools or a Verilog language 
license from Cadence, and a large number started to back the 
VHDL [2] language as a public standard. VHDL was developed in 
the early 1980s for the US Department of Defense to provide a con- 
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sistent way to document chip designs, and it was first approved as 
an IEEE standard in 1987. 



B.2 Opening up Verilog: towards an IEEE standard 



HDL users in Europe and Japan are particularly keen on adopting 
standards, and not proprietary solutions. They started to adopt 
VHDL, as it was already public and an IEEE standard. Even though 
VHDL was originally developed as a language for documenting 
design, EDA vendors developed tools around it, and their custom- 
ers starting using it for RTL design and verification. 

In 1989, under the guidance of its Director of Strategic Marketing, 
Venk Shukla, Cadence responded to this swing away from Verilog 
by forming Open Verilog International (OVI), as a non-profit 
industry standards organization, donating Verilog to it, and thus 
placing the Verilog language and PLI into the public domain. This 
version became know as OVI Verilog 1.0. 

OVI promoted and marketed Verilog and, by working with the 
IEEE, turned the Verilog HDL into the IEEE 1364 Verilog HDL 
(Verilog-95). There was a false start to this within OVI, as many 
people wanted to extend Verilog, and thus OVI quickly made many 
changes to the Verilog language, as donated by Cadence. This Ver- 
ilog 2.0 from OVI was rejected by the IEEE committee, who 
selected the proven and widely used OVI Verilog 1.0 as the basis 
for IEEE 1364. 

This OVI promotion and marketing, and IEEE standardization, 
stemmed the move away from Verilog. Competitive simulators 
such as VCS and NC-Verilog appeared and, by 2000, Verilog 
returned to being the dominant HDL. 



B.3 Co-Design Automation 



As Verilog was becoming standardized in the mid 1990s, discus- 
sion started regarding on what languages and/or language features 
were needed at higher levels of abstraction. Verilog was behind 
VHDL in this respect. 
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During 1995, Peter Flake and Simon Davidmann started collaborat- 
ing again to develop their ideas on next generation simulators and 
languages for design and verification. In September 1997, they 
founded Co-Design Automation, Inc., which was incorporated in 
California with the specific business plan of developing a new sim- 
ulator and a new language — ultimately called SUPERLOG, being a 
superset of Verilog — to augment the then current HDLs. 

Many people have asked why the company that developed SUPER- 
LOG (SystemVerilog) was called Co-Design, when the outcome of 
their endeavors was to evolve Verilog from being an HDL to being 
an integrated Hardware Design and Verification Language 
(HDVL). The answer is simple... the original business plan was to 
evolve Verilog to be of use for hardware design, software design, 
and verification — i.e. to be useful for codesign as well as verifica- 
tion — which was a significant challenge. The company succeeded 
in evolving Verilog to unify the design and verification tasks. 

Co-Design obtained its first seed round of funding in June 1998. 
One of the seed investors was Andy Bechtolsheim, a co-founder of 
Sun Microsystems and later an engineering VP at Cisco. He was 
very interested to see a new HDL developed to make digital design- 
ers more productive. Another key investor in the Co-Design seed 
round was Rich Davenport, CEO of Simulation Technologies 
(developer of the VirSim simulation debugger), who shared the 
founders’ vision and who became a Co-Design board member from 
inception through to final successful acquisition. Other early inves- 
tors were John Sanguinetti, the developer of VCS, who went on to 
found C2/Cynapps/Forte and develop C/C++ synthesis, and Rajeev 
Madhavan who was CEO and a founder of Ambit, and then of 
Magma. Many of the key technology visionaries in EDA were 
backing the Co-Design vision of extending Verilog and creating a 
super Verilog. 



B.4 Moving to C++ class libraries or Java: the land of the free? 



April 15, 1998 was a milestone, as it saw the formation and first 
meeting of the OVI Architectural Language Committee (ALC). 
This included personnel from Cisco, Sun, National, Motorola, 
Cadence (owners of NC-Verilog), Viewlogic (owners of VCS) and 
Co-Design. It was convened to discuss ‘developing an architec- 
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tural/algorithmic language with verification and analysis orienta- 
tion with a processor modeling extension that is targeted for 
advanced processor architecture development. This O VI committee 
work started with all good intentions, but by January 1999 had 
become de focussed by many people steering the committee down 
the route of adopting existing software languages or class librar- 
ies — the two main camps being based around C++ class libraries 
(two proposals) and Java based methodologies (also two propos- 
als). 

Even though there were a few believers that a better Verilog was 
needed, most people in the EDA industry were getting excited 
about C++ class libraries or Java based approaches to hardware 
design. This was the middle of the late 1990s internet dot com 
‘free’ bubble, and so many people thought that it would be a good 
idea to find a way to use C++ or Java as a digital design language, 
and get all the EDA tools they would need for free ©. 



B.5 Marketing SUPERLOG 



The Co-Design team saw the situation in a different light. In May 
1999, Dave Keif joined Co-Design as VP marketing and started to 
develop plans for informing the world about the company’s direc- 
tion for a unified HDL/HVL. Co-Design attended the June 1999 
DAC conference and exhibition with a tiny 10ft by 10ft booth. An 
informative article by Peter Clarke in the US EE Times [EE1] the 
week before the conference caused a very busy time for Co-Design 
staff at the show. All employees (except Peter Heller, the CFO) 
attended (see Photo 2) and, being a small company, the software 
development engineers had to be pressed into giving demos at the 
exhibition booth. 

At DAC 1999, the hot topic was definitely new design and verifica- 
tion languages. SUPERLOG/Co-Design was listed as one of the 10 
‘must see’ items of DAC by Gary Smith of Dataquest [DQ1]. To 
quote from Gary in the EE Times article: “The Verilog guys are 
saying they have run out of steam. The VHDL guys are pretty much 
saying VHDL is dead. C++ is not going to work at all, and the C 
guys can’t come up with a solution unless they really restrict the 
problem. Co-Design has a fair chance of establishing its language.” 
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Photo 2: The whole of Co-Design attends DAC 1999 to launch the SUPERLOG 
debate — (left to right) Dave Keif, Christian Burisch, Lee Moore, James Kenney, 
Simon Davidmann, Peter Flake, Matthew Hall. 



In January 2000, Peter Flake made the first public technical presen- 
tation of SUPERLOG at Asia Pacific DAC (ASP-DAC) in Japan 
[3]. This was followed by another presentation at the HDL Confer- 
ence (HDLCon) in February [4]. Later that year, in September, 
Simon Davidmann made a keynote presentation at the Forum on 
Design Languages conference (FDL) that explained the process of 
developing languages [5]. 

The idea was to add the capabilities of software programming lan- 
guages and high level verification languages, all within the one 
familiar design language. The SUPERLOG language was continu- 
ally being polished from inception through 2001, and was proven in 
Co-Design’s simulator (SYSTEMSIM) and in its translator to Ver- 
ilog (SYSTEMEX). 
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During 2000, as the Co-Design products were gaining acceptance 
with early adopters, it became obvious to many sophisticated EDA 
watchers and users that evolving the known and well liked Verilog 
HDL into a super HDL was a better approach than replacing it with 
a software language. This is exactly what Co-Design had pioneered 
with its unified HDL/HVL: SUPERLOG. Co-Design was placed 
under pressure by some of its partners and customers to accelerate 
the process of getting SUPERLOG standardized as the next genera- 
tion of Verilog. Many of the engineers participating in developing 
the IEEE 1364 Verilog-2001 specification got very excited about 
SUPERLOG, and were also keen to see it become folded into the 
next IEEE Verilog. The press picked up on these undercurrents, and 
in August 2000 Richard Goering of EE Times stated “Wouldn’t it 
be funny if the EDA vendors pushing C/C++ for hardware design 
were wrong, and Co-Design’s SUPERLOG language wound up as 
the real next generation HDL?” [EE2]. Also, John Cooley started to 
have many users and supporters writing into ESNUG about their 
like of SUPERLOG and its direction, prompting an article in 
November 2000 on “the SUPERLOG evolution” [EE3]. 

Several EDA companies became supportive of the SUPERLOG 
vision, and wanted to get more involved. Dave Keif responded to 
this, and created the S2K (SUPERLOG 2000) partners program, 
where members could get early access to SUPERLOG language 
technology, and help SUPERLOG on its path to industry adoption 
and standardization. By early 2001, the EDA world of languages 
started to settle into two camps: the ‘evolve Verilog camp’ centered 
around SUPERLOG for next generation RTL methodologies, and 
the C++ class library approach centered around the open source 
SystemC (6] class library put in the public domain by Synopsys, for 
high level systems modeling. While there was all this discussion 
regarding EDA languages, there was little, if any, discussion about 
evolving VHDL. 

A tutorial [7] at the HDL Conference (HDLCon) in February 2001 
was the first detailed disclosure of the SUPERLOG syntax. A year 
later at HDLCon in March 2002, Co-Design presented two tutori- 
als: one on verification using SUPERLOG’s verification features 
[8] and the other on SystemVerilog (SUPERLOG) interfaces [9] 
and communication based design. 
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When building SUPERLOG, the hard challenge for the Co-Design 
language development team was the balance of controlling the lan- 
guage to make it easy, quick, and efficient to modify and improve 
as needed, while having a path to openness and standardization. 
The solution to this dilemma came with the donation of the design 
subset of SUPERLOG to Accellera 1 and the creation of what was 
initially called the Accellera Verilog++ committee. The design part 
of SUPERLOG was termed the Extended Synthesizable Subset 
(ESS) and this SUPERLOG ESS was officially donated to Accel- 
lera in May 2001. 



B.6 SystemVerilog 



From May 2001 through May 2002, a small group of dedicated 
HDL enthusiasts, EDA developers, IEEE 1364 committee mem- 
bers, and users worked hard in the Accellera committee, focused on 
turning the Co-Design donation of the SUPERLOG ESS into a pub- 
lic standard. Accellera was very keen on working on the SUPER- 
LOG donation, and the Accellera Board Chairman, Dennis Brophy, 
and Technical Committee Chairman, Vassilios Gerousis, were very 
supportive. Co-Design had up to 25% of its employees attending 
regular Accellera committee meetings. 

In May 2002, this new language extension to the Verilog HDL was 
approved by the Accellera board of directors, and became known as 
SystemVerilog 3.0 [10]. Copies of the Accellera standard were dis- 
tributed at the June DAC 2002. 

Meanwhile, it was announced that Intel had made a strategic invest- 
ment in Co-Design. Intel has a policy of not endorsing suppliers’ 
products, but it is interesting to note that, a year later, at DAC 2002, 
Intel was one of the public supporters of the SystemVerilog 3.0 
standard. There they said that they had been using it for a while, 



1. OVI’s focus was Verilog only and, for almost 10 years, promoted Verilog with the annual 
International Verilog Conference in Santa Clara. With the demise of support and develop- 
ment for the VHDL language, OVI merged with VHDL International to form Accellera, and 
IVC became the HDL Conference (HDLCon), now recently renamed Design and Verifica- 
tion Conference (DVCon) (www.dvcon.org). Accellera is now a language neutral non-profit 
organization that promotes EDA language standards (www.accellera.org). 





B.7 SystemVerilog 3.1 and beyond 

After the June DAC 2002, work started in Accellera on extending 
SystemVerilog into the testbench area, and to improve the asser- 
tions into a full temporal logic. Donations were made by other com- 



Photo 3: DAC 2002 was attended by most of the Co-Design staff. 
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and saw it as fundamental technology for future advanced proces- 
sor design. 



Almost all of SystemVerilog 3.0 is SUPERLOG, but not vice- 
versa. Much of SUPERLOG was not donated to Accellera for Sys- 
temVerilog 3.0. A couple of features were added by the committee: 
data types for enumerations and implicit port connections. The 
SUPERLOG Design Assertion Subset was developed concurrently 
with the committee. 
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panies, with the majority coming from Synopsys. This evolution of 
SystemVerilog, currently at revision 3.1, was released at DAC 
2003. 

Co-Design was acquired by Synopsys in September 2002, and sev- 
eral Co-Design staff stayed involved with the Accellera System- 
Verilog work. 

At the Design and Verification Conference (DVCon) held in San 
Jose in February 2003, Aart de Geus, co-founder, Chairman, and 
CEO of Synopsys, delivered the keynote speech, and explained 
how SystemVerilog was a key component of his company’s lan- 
guage strategy moving forward. 

The benefit to users is, of course, that they will be able to design 
and verify in much more efficient ways than was previously possi- 
ble with the older, lower level HDL capabilities. 




Figure 11-1: History: Evolution from HILO, Verilog, SUPERLOG to SystemVerilog 
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B.9 Who’s Who in the evolution of SUPERLOG and SystemVerilog 3,0 



Peter Flake - inventor of HILO language, the first HDL with tim- 
ing, and developer of test generators for HILO- land HILO-2. Co- 
founder of Co-Design and developer of SUPERLOG/SystemVer- 
ilog. 

Phil Moorby - developed fault free and fault simulator for HILO-2. 
Invented the Verilog language and the Verilog-XL simulator. 
Became Chief Scientist at Co-Design. 

Simon Davidmann - developer in the HILO team and first Euro- 
pean employee of Gateway who developed Verilog. Joined Chrono- 
logic Simulation as one of first employees to market and sell VCS 
simulator in Europe. Co-Founder and CEO of Co-Design and co- 
developer of SUPERLOG/System Verilog. 

Martin Harding - started and managed ASIC Business Group 
within Gateway making Verilog a de facto standard with ASIC ven- 
dors. Seed round investor in Co-Design. 

Venk Shukla - Strategic marketing director within Cadence who 
initiated the formation of OVI to open up the Verilog language and 
put it on its path to IEEE standardization. Became a board member 
of Co-Design. 

Andy Bechtolsheim - a co-founder of Sun Microsystems, devel- 
oper of the Sun workstations, currently engineering VP at Cisco, 
and latterly a Silicon Valley angel investor. Liked vision of new 
HDL and became seed round investor in Co-Design. 

Rich Davenport - Sales director at Gateway, founder of Simulation 
Technologies, and President/COO of Summit Design. Became lead 
investor in Co-Design seed round in 1998, shared the vision of uni- 
fied design/verification language and tool. Became Co-Design 
board member from inception through to successful acquisition. 

John Sanguinetti - founder and CEO of Chronologic Simulation, 
developer of VCS, the first compiled Verilog simulator. Shared the 
Co-Design vision of a unified HDL and became a seed round inves- 
tor. Later John focused on C++ based synthesis technologies within 
Forte Design. 





370 



SystemVerilog for Design 



Rajeev Madhavan - founder of LogicVision, Ambit Design Sys- 
tems and Magma Design Automation. Saw significant benefits in 
unifying the different HDL and HVL requirements and became 
seed round investor in Co-Design. 

Dave Keif - an early user of Verilog. Moved into marketing and 
was responsible for the product marketing of Cadence’s NC- Ver- 
ilog simulator. VP Marketing at Co-Design. 

Stuart Sutherland, Cliff Cummings, Stefen Boyd, Mike McNamara, 
Anders Norstom, Bob Beckwith, Tom Fitzpatrick, and Kurt Baty - 
IEEE Verilog developers and early supporters of SUPERLOG 

Richard Goering and Peter Clarke - editors with EE Times in the 
US, kept a watchful eye on the ‘new’ language debate as it evolved, 
and played a key role in the industry by assessing the players and 
their messages, and ensuring that the lively discussions were made 
public and brought to their readers’ attention. Over a period of 2 
years, there were many front cover articles in EE Times that cov- 
ered the language debate with 5 of them featuring Co-Design. 

Gary Smith - Chief EDA Analyst at Gartner Dataquest. Closely 
watches evolving technologies and identifies trends. In 1999 identi- 
fied Co-Design and SUPERLOG as a potential winner. 

Raj Singh and Raj Parekh - partners at Redwood Ventures, both 
with significant histories in design and EDA. Started a venture cap- 
ital business to invest in new technologies, became intrigued with 
Co-Design opportunity, and invested in first venture round. Held 
board seat from investment through acquisition. 

Peter Heller - co-founder and CFO of Co-Design - involved with 
the creation of the European offices of many successful EDA star- 
tups including Verilog developers Gateway Design Automation and 
VCS developers Chronologic Simulation - structured Co-Design 
with US and UK legal entities and managed all legal and financial 
issues from startup through financing to ultimate acquisition by 
Synopsys. 

Don Thomas - Professor at CMU, early pioneer in HDL methodol- 
ogies, wrote the first book on Verilog with Phil Moorby. Don was a 
member of Co-Design’s Technical Advisory Board from the begin- 
ning. 





Index 



Symbols 

!?= operator 140 

$bits system function 99 

Scast dynamic cast function 44, 60 

Sdimensions system function 97 

$high system function 98 

Sincrement system function 98 

$left system function 97 

Slow system function 98 

Sright system function 97 

Ssize system function 98 

%= operator 138 

&= operator 138 

*= operator 138 

++ operator 134-137 

+= operator 138 

.* port connections 202-203, 208 

.*. port connections 237 

.name port connections 198-202, 237 

/= operator 138 

«<= operator 138 

«= operator 138 

-= operator 138 

— operator 134-137 

=?= operator 140 

»= operator 138 

»>= operator 138 

@* 113 

A = operator 138 

|= operator 138 

' 9 

'» 10 

' ' 10 

'define 9, 10 

Numerics 

2-state data types 26, 177-182 

2-state operations 142 

4-state data types 25 



A 

Accellera standards organization 2 

acknowledgements xxviii 

alias statement 204-209 

always @* 113 

always_comb 28, 108-115, 159 

alwaysff. 28, 117 

alwaysjatch 28, 115-117 

anonymous enumerated type 58 

anonymous structure 67 

anonymous union 75 

arrays 

associative 101 

copying 90 

declaration and usage 80-99 

dynamic 100 

indexing 92 

initializing 86 

packed 83-85 

passing to tasks and functions 127 

query functions 97 

sparse 101 

unpacked 80 

assignment operators 137-139 

associative arrays 101 

automatic functions 118 

automatic tasks 118 

automatic variables 32-38 

B 

Backus-Naur Form 317 

begin... end 

block names 153 

optional in tasks and functions 1 19 

variable declarations 220 

behavioral modeling 292 

bit data type 25 

bit-stream casting 91 

BNF 317 




372 



Verilog-2001: A Guide to the New Features of the Verilog HDL 



break statement 152 

byte data type 25 



C 

case equality operators 140 

case expression 157 

case selection item 157 

case statements 

priority 160-162 

unique 157-162, 168, 172 

casting 

$cast dynamic casting 44, 60 

bit-stream 91 

cast operator 43, 60, 143, 144 

companion book on verification ....xxiii, xxvii 

compilation unit 

description and usage 11-18 

extern module declarations 185 

structure declarations 67 

timeunit declarations 22 

typedef declarations 50 

variable initialization 34 

compilation-unit scope, definition of. 11 

const 46 

constants 46 

continue statement 151 



D 

data types 

2-state 26 

4-state 25 

relaxed rules 27 

decrement operator 134-137 

default structure values 69 

disable statement 121, 150 

do...while loop 148-150 

dynamic arrays 100 

dynamic casting 44 

E 

enumerated types 

anonymous 58 

declaration and usage 52-64 

modeling FSMs 168-177 

examples 

about xxv 

obtaining copies of xxvi 

export declaration 256 

extern declaration 256 

extern declarations 1 84-186 

extern forkjoin 257 

external declarations 1 1 



F 

first method 61 

for loop enhancements 144-148 

full_case 161 

functions 

automatic 118 

begin.. .end 119 

default argument type and direction 125 

default argument value 126 

empty 131 

formal arguments 124 

named endfunction 1 3 1 

passing arguments by name 123 

reference arguments 127-130 

return statement 120 

void 121 

G 

global declarations 13 

H 

HDVL, definition of 2 

I 

IEEE 1364 Verilog standard xxvii, 1 

IEEE 1364.1 Verilog synthesis standard xxvii, 

106 

if statements 

priority 165 

unique 163-165 

import keyword 251 

increment operator 134-137 

inside operator 141 

int data type 25 

interfaces 

concepts 226-235 

contents 235 

declarations 236 

exporting methods 255 

extern forkjoin 257 

importing methods 251 

methods 251-258 

modports 243-250 

module port declarations, explicit 239 

module port declarations, generic 240 

parameterized 259 

procedural blocks 258 

referencing signal within 241 

L 

labels 156 

Language Reference Manual 




373 



SystemVerilog for Design 



SystemVerilog xxvii 

Verilog xxvii 

last method 61 

literal values 8 

logic datatype 25 

longint data type 25 

LRM 

SystemVerilog xxvii 

Verilog xxvii 



M 

methods 

first 

last 

name 

next 

num 

prev 

module prototypes 

N 

name method 

named end of blocks 

named endmodule 

named port connections 

nested interface declarations 

nested modules 

net aliasing 

next method 

num method 

O 

operators 

!?= 

%= 

&= 

*= 

++ 

+= 

/= 

«<= 

«= 



»=... 

»>= 



inside 

ordered port connections. 



61 

61 

62 

62 

62 

62 

184-186 



62 

186 

186 

193-197 

239 

187-193 

204-209 

62 

62 



134-137 

140 

138 

138 

138 

134-137 

138 

138 

138 

138 

138 

140 

138 

138 

138 

138 

141 

193 



P 

packages 13 

packed arrays 83-85 

packed structures 70 

packed unions 76 

parallel_case 161 

parameter 46 

parameterized data types 219 

port connections 

* 202-203, 208, 237 

.name 198-202, 237 

data type rules 210 

named 193-197 

ordered 193 

ref ports 214 

port declarations, simplified 218 

prev method 62 

priority case 160-162 

priority if 165 

prototypes 

interface task/function 252 

modules 184-186 

R 

ref module ports 214 

ref task/function arguments 128-130 

return statement 120, 152 

S 

shortint data type 25 

shortreal data type 25 

signed modifier 31 

sizeof, see $bits 

sparse arrays 101 

statement labels 156 

static variables 32-38 

strings 102 

structures 

anonymous 67 

declaration and usage 66-74 

default values 69 

initializing 68 

packed 70 

passing to tasks and functions 127 

unpacked 70 

synthesis guidelines 

Sbits 99 

++ and — operators 137 

2-state and 4-state data types 27 

always_comb 118 

alwaysff. 118 

always_latch 118 




374 



Verilog-2001: A Guide to the New Features of the Verilog HDL 



array query system functions 99 

assignment operators 138 

automatic variables 37 

break and continue 153 

casting 45 

do... while loops 150 

external compilation-unit declarations.... 14 

for loops 148 

inside operator 142 

interfaces 240, 247, 255 

priority case 161 

priority if 165 

ref ports 216 

return 153 

structures 74 

unions 78 

unique case 161, 172, 174 

unique if 165 

void functions 122 

wild equality operator 141 

system functions 

Sbits 99 

Sdimensions 97 

$high 98 

Sincrement 98 

$left 97 

Slow 98 

Sright 97 

Ssize 98 

SystemVerilog 3.0 2 

SystemVerilog 3.1 3 

SystemVerilog 3.1a 3 

SystemVerilog LRM xxvii 

T 

tasks 

automatic 1 18 

begin...end 119 

default argument type and direction 125 

default argument value 126 

empty 131 

named endtask 131 

passing arguments by name 123 

reference arguments 127-130 

return statement 120 

timeprecision statement 22-24 

timeunit statement 22-24 

Transaction Level Modeling 291-316 

type casting 43-45 

type keyword ...219 

typedef, declaration and usage 49-51 



U 

unions 



anonymous 


75 


declaration and usage.. 


74-79 


packed 


76 


unpacked 


75 


unique case 


.. 157-162, 168, 172 


unique if 


163-165 


unnamed blocks 


221 


unpacked arrays 


80 


unpacked structures 


70 


unpacked unions 


75 


unsigned modifier 


31 


user-defined types 


49-51 


V 


variable initialization 


34-43 


vectors, filling 


8 


void data type 


25 


void functions 


121 




